On Thu, Jul 01, 2010 at 12:51:04PM +0000, Daniel Kozlowski wrote: > Yee-Ting Li <yee379 <at> gmail.com> writes: > > > > > Hi, > > > > i think my btrfs volume is hosed.... it mounts okay, but iostat shows /dev/sdg > on 100% load. dmesg shows lots > > of 'parent transid verify failed on x wanted y found z'. then after a while i > can't read from it (access to the > > filesystem freezes). > > > > the machine had crashed (prob from some other process), and upon reboot i've > been experience this problem since. > > > > can anyone provide any guidance in how to proceed? > > > > cheers, > > > > Yee. > > I am also having the same problem with a slightly different setup. In My case I > cannot mount the filesystem. What is your hardware setup here? Including write cache settings. Did you have craces with 2.6.35-rc1 or rc2? > mount, btrfs-endio-met and kblockd/0 will all > continually run until the system freezes up and requires a power cycle. I have > both the kernel module and the tools checked out from git so if you have any > ideas on fix's I can build them and test it out. > > here is some information about my setup > [root@solution ~]# uname -a > Linux solution.bcig 2.6.35-0.13.rc3.git2.fc14.x86_64 #1 SMP Mon Jun 28 19:27:35 > UTC 2010 x86_64 x86_64 x86_64 GNU/Linux > [root@solution ~]# > > [root@solution ~]# btrfs-show > Label: store uuid: 4ba1cc6b-e12a-454a-a064-f4019312c063 > Total devices 7 FS bytes used 1.15TB > devid 1 size 931.51GB used 415.55GB path /dev/sdb > devid 2 size 931.51GB used 518.50GB path /dev/sdc > devid 3 size 931.51GB used 342.04GB path /dev/sdd > devid 4 size 931.51GB used 523.54GB path /dev/sde > devid 5 size 465.76GB used 402.54GB path /dev/sdf > devid 6 size 465.76GB used 382.54GB path /dev/sdg > devid 7 size 465.76GB used 367.54GB path /dev/sdh > > Btrfs v0.19-16-g075587c-dirty > [root@solution ~]# > > [root@solution ~]# tail -n 12 /var/log/messages > Jul 1 04:47:03 solution kernel: parent transid verify failed on 1682196926464 > wanted 285263 found 283510 > Jul 1 04:47:08 solution kernel: verify_parent_transid: 9244 callbacks > suppressed > Jul 1 04:47:08 solution kernel: parent transid verify failed on 1682196926464 > wanted 285263 found 283510 > Jul 1 04:47:08 solution kernel: parent transid verify failed on 1682196926464 > wanted 285263 found 283510 > Jul 1 04:47:08 solution kernel: parent transid verify failed on 1682196926464 > wanted 285263 found 283510 > Jul 1 04:47:08 solution kernel: parent transid verify failed on 1682196926464 > wanted 285263 found 283510 > Jul 1 04:47:08 solution kernel: parent transid verify failed on 1682196926464 > wanted 285263 found 283510 > Jul 1 04:47:08 solution kernel: parent transid verify failed on 1682196926464 > wanted 285263 found 283510 > Jul 1 04:47:08 solution kernel: parent transid verify failed on 1682196926464 > wanted 285263 found 283510 > Jul 1 04:47:08 solution kernel: parent transid verify failed on 1682196926464 > wanted 285263 found 283510 > Jul 1 04:47:08 solution kernel: parent transid verify failed on 1682196926464 > wanted 285263 found 283510 > Jul 1 04:47:08 solution kernel: parent transid verify failed on 1682196926464 > wanted 285263 found 283510 Looks like we're looping on a single block. What happens when you dmesg -n1 to cut down on the console traffic? If that doesn't help we can change it to spit a stack trace to figure out where the looping is happening. We should be erroring out instead of hitting it over and over again. -chris -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
