I can wait a couple of days for the new tool - glad to know that there
is still hope. If the new btrfsck isn't available within a week or so
I might hit you up for that patch. Thanks!
- Craig
On Wed, May 25, 2011 at 2:28 PM, Josef Bacik <jo...@redhat.com> wrote:
> 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
>
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
