Re: Will "btrfs check --repair" fix the mounting problem?

[Qu Wenruo <quwenruo@cn.fujitsu.com>]

Ivan Sizov wrote on 2015/12/15 09:34 +0000:
> 2015-12-15 1:42 GMT+00:00 Qu Wenruo <quwenruo@cn.fujitsu.com>:
>> You'll see output like the following:
>> Well block 29491200(gen: 5 level: 0) seems good, and it matches superblock
>> Well block 29376512(gen: 4 level: 0) seems good, but generation/level
>> doesn't match, want gen: 5 level: 0
>>
>> The match one is not what you're looking for.
>> Try the one whose generation is a little smaller than match one.
>>
>> Then use btrfsck to test if it's OK:
>> $ btrfsck -r <BYTENR> /dev/sda1
>>
>> Try 2~5 times with bytenr whose generation is near the match one.
>> If you're in good luck, you will find one doesn't crash btrfsck.
>>
>> And if that doesn't produce much error, then you can try btrfsck --repair -r
>> <BYTENR> to fix it and try mount.
>
> I've found a root that doesn't produce backtrace. But extent/chunk
> allocation errors was found:
>
> $ sudo btrfsck --tree-root 535461888 /dev/sda1
> parent transid verify failed on 535461888 wanted 21154 found 21150
> parent transid verify failed on 535461888 wanted 21154 found 21150
> Ignoring transid failure
> checking extents
> parent transid verify failed on 459292672 wanted 21148 found 21153
> parent transid verify failed on 459292672 wanted 21148 found 21153

Transid failure is OK.

> Ignoring transid failure
> bad block 459292672
> Errors found in extent allocation tree or chunk allocation
> parent transid verify failed on 459292672 wanted 21148 found 21153
>
> Should I ignore those errors and run btrfsck --repair? Or
> --init-extent-tree is needed?
>
Did it btrfsck has other complain?
And how is the generation difference between the one you're using and 
the one in superblock?

If the generation difference is larger than 1, I'd recommend not to run 
'--repair' nor '--init-extent-tree'

If the difference is only 1, and btrfsck doesn't report problems other 
than transid error, I'd like to try --repair or --init-extent-tree.

But there is *NO* guarantee and it may still make case worse.

Thanks,
Qu