Re: parent transid verify failures on 2.6.39

[Josef Bacik <josef@redhat.com>]

On 05/25/2011 03:06 PM, Craig Johnson wrote:
> After doing an upgrade to 2.6.39 from 2.6.39-rc7, I am unable to mount
> my 3 disk btrfs volume.  It was a clean reboot, which makes it all the
> more puzzling.  This is what I'm getting:
> 
> 
> [68808.339109] device fsid a941511a96bcbfb8-8c123cb07aa6aaa1 devid 2
> transid 339584 /dev/sdc1
> [68808.340354] device fsid a941511a96bcbfb8-8c123cb07aa6aaa1 devid 1
> transid 339584 /dev/sda1
> [68808.340774] device fsid a941511a96bcbfb8-8c123cb07aa6aaa1 devid 3
> transid 339584 /dev/sdb1
> 
> [70106.913668] btrfs: disk space caching is enabled
> [70106.968648] parent transid verify failed on 6038227976192 wanted
> 337418 found 337853
> [70106.969031] parent transid verify failed on 6038227976192 wanted
> 337418 found 337853
> [70106.969403] parent transid verify failed on 6038227976192 wanted
> 337418 found 337853
> [70106.969671] parent transid verify failed on 6038227976192 wanted
> 337418 found 337853
> [70106.969691] parent transid verify failed on 6038227976192 wanted
> 337418 found 337853
> [70106.969704] Failed to read block groups: -5
> [70107.050658] btrfs: open_ctree failed
> 
> I went to run a btrfsck, but found out that I needed to compile with
> the tmp branch or I would get an unsupported features message (lzo and
> space_cache).  After compiling that, when I run btrfsck, I get this:
> 
> parent transid verify failed on 6038227976192 wanted 337418 found 337853
> parent transid verify failed on 6038227976192 wanted 337418 found 337853
> parent transid verify failed on 6038227976192 wanted 337418 found 337853
> 
> And then it stops.  This happens with btrfs-debug-tree, or
> btrfs-select-super.  I've tried it on sda1, sdb1, and sdc1 and also
> with -s 0, -s 1, and -s 2.  Dmesg shows a segfault:
> 
> [71775.589462] btrfsck[14453]: segfault at c4 ip 000000000040e477 sp
> 00007fffa9eb4d30 error 4 in btrfsck[400000+21000]
> 
> For fun, I ran it through gdb and I got this:
> 
> Program received signal SIGSEGV, Segmentation fault.
> find_first_block_group (root=0x61d1b0, path=0x61ef10, key=0x7fffffffe240)
>     at extent-tree.c:3028
> 3028                    if (slot >= btrfs_header_nritems(leaf)) {
> 
> 
> 
> Is there any hope of recovery here?  Not the end of the world if the
> volume is lost, but it would be a bit of a pain and I'm at a loss as
> to why it happened.  I tried mounting with the new integration-test
> branch just for fun, but there's no difference on the mounting.  Any
> help that could be provided would be immensely appreciated.  Thanks!
> 

So I have a patch I can give you that will possibly help you recover
your data if you don't have backups, or you can wait a couple of days
(hopefully) for the new btrfsck tool that will be much better than the
hack I can give you.  Thanks,

Josef