On 8 July 2010 01:21, Daniel Kozlowski <dan.kozlowski@xxxxxxxxx> wrote: > On Tue, Jul 6, 2010 at 8:19 PM, Chris Mason <chris.mason@xxxxxxxxxx> wrote: >>> 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? > > My setup is > > Eight hard Drive > four 1TB Drives > four 500GB Drives > All drives are connected through a 3ware Inc 9550SX SATA-II RAID PCI-X card > The card is configured to export all drives essentially acting as a > SATA port multiplier. (drives show up sdb - sdi) > Drives are configured in btrfs raid0 > Filesystem is mounted using: > mount -t btrfs /dev/sdb /opt > > I have been able to lock up the system on > 2.6.33.5-124.fc13.x86_64 > 2.6.35-0.13.rc3.git2.fc14.x86_64 > 2.6.35-0.23.rc3.git6.fc14.x86_64 > and > 2.6.35-0.23.rc3.git6.fc14.x86_64 with a DKMS build of the btrfs module > (Btrfs v0.19-16-g075587c-dirty) > > If you would like me to pull out another version of the kernel or roll > back specific commits from the kernel module I can > > I have been able to get different responses form different version > 2.6.33.* - This will mount the volume but will hang shortly after > mounting when reading data form the filesystem ( ls /opt) writes a > bunch of transid verify failed messages hangs on ls > 2.6.34.* - Will not mount at all still gives the transid verify failed > hands on mount > >> >> Looks like we're looping on a single block. What happens when you >> dmesg -n1 to cut down on the console traffic? >> > Nothing changes I still have endless repeats of > > parent transid verify failed on 1682586464256 wanted 285114 found 11257 > >> 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. > > In my kernel noviceness i tried attaching gdb to the btrfs-endio-met, > however apparently you can't attach gdb to a kernel thread like that > If you could assist me in obtaining a call trace I will gladly attempt > to resolve the matter. For grabbing kernel backtraces: $ sudo -s # dmesg -c >/dev/null # echo t >/proc/sysrq-trigger # dmesg >backtraces.txt (there are other ways with The problem is that you'll be taking instantaneous snapshots, which may or may not be representative of the main looping, but over a few shots should be. Thanks, Daniel -- Daniel J Blueman -- 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
