[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: parent transid verify failures on 2.6.39



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

Could I try your hack, pretty please? If there's any chance it could either resolve this problem

	http://www.mail-archive.com/linux-btrfs@xxxxxxxxxxxxxxx/msg10683.html ,

or at least restore the data from the filesystem, then I'd like to give it a go. Waiting for the new btrfsck is currently not an option for me :-)

Andrej

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature


[Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Photo]     [Yosemite News]    [Yosemite Photos]    [Free Online Dating]     [Linux Kernel]     [Linux SCSI]     [XFree86]

Add to Google Powered by Linux