Ivan Sizov wrote on 2015/12/15 09:34 +0000:
2015-12-15 1:42 GMT+00:00 Qu Wenruo <quwenruo@xxxxxxxxxxxxxx>:
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
--
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
