Re: "parent transid verify failed" and mount usebackuproot does not seem to work

[Qu Wenruo <quwenruo.btrfs@gmx.com>]

[-- Attachment #1.1: Type: text/plain, Size: 4662 bytes --]



On 2020/7/1 上午3:41, Illia Bobyr wrote:
> Hi,
> 
> I have a btrfs with bcache setup that failed during a boot yesterday.
> There is one SSD with bcache that is used as a cache for 3 btrfs HDDs.
> 
> Reading through a number of discussions, I've decided to ask for advice here.
> Should I be running "btrfs check --recover"?
> 
> The last message in the dmesg log is this one:
> 
> Btrfs loaded, crc32c=crc32c-intel
> BTRFS: device label root devid 3 transid 138434 /dev/bcache2 scanned
> by btrfs (341)
> BTRFS: device label root devid 2 transid 138434 /dev/bcache1 scanned
> by btrfs (341)
> BTRFS: device label root devid 1 transid 138434 /dev/bcache0 scanned
> by btrfs (341)
> BTRFS info (device bcache0): disk space caching is enabled
> BTRFS info (device bcache0): has skinny extents
> BTRFS error (device bcache0): parent transid verify failed on
> 16984159518720 wanted 138414 found 138207
> BTRFS error (device bcache0): parent transid verify failed on
> 16984159518720 wanted 138414 found 138207
> BTRFS error (device bcache0): open_ctree failed

Looks like some tree blocks not written back correctly.

Considering we don't have known write back related bugs with 5.6, I
guess bcache may be involved again?

> 
> Trying to mount it in the recovery mode does not seem to work:
> 
> (initramfs) mount -t btrfs -o ro,usebackuproot /dev/bcache0 /mnt
> BTRFS info (device bcache1): trying to use backup root at mount time
> BTRFS info (device bcache1): disk space caching is enabled
> BTRFS info (device bcache1): has skinny extents
> BTRFS error (device bcache1): parent transid verify failed on
> 16984159518720 wanted 138414 found 138207
> BTRFS error (device bcache1): parent transid verify failed on
> 16984159518720 wanted 138414 found 138207
> BTRFS error (device bcache1): parent transid verify failed on
> 16984173199360 wanted 138433 found 138195
> BTRFS error (device bcache1): parent transid verify failed on
> 16984173199360 wanted 138433 found 138195
> BTRFS warning (device bcache1): failed to read tree root
> BTRFS error (device bcache1): parent transid verify failed on
> 16984171298816 wanted 138431 found 131157
> BTRFS error (device bcache1): parent transid verify failed on
> 16984171298816 wanted 138431 found 131157
> BTRFS warning (device bcache1): failed to read tree root
> BTRFS critical (device bcache1): corrupt leaf: block=16984183013376
> slot=36 extent bytenr=11447166291968 len=262144 invalid generation,
> have 138434 expect (0, 138433]
> BTRFS error (device bcache1): block=16984183013376 read time tree
> block corruption detected
> BTRFS critical (device bcache1): corrupt leaf: block=16984183013376
> slot=36 extent bytenr=11447166291968 len=262144 invalid generation,
> have 138434 expect (0, 138433]
> BTRFS error (device bcache1): block=16984183013376 read time tree
> block corruption detected
> BTRFS warning (device bcache1): failed to read tree root
> BUG: kernel NULL pointer dereference, address: 000000000000001f
> #PF: supervisor read access in kernel mode
> 
> <a stack trace follows>
> 
> (initramfs) btrfs --version
> btrfs-progs v5.4.1
> 
> (initramfs) uname -a
> Linux (none) 5.6.11-050611-generic #202005061022 SMP Wed May 6 10:27:04
> UTC 2020 x86_64 GNU/Linux
> 
> (initramfs) btrfs fi show
> Label: 'root' uuid: 0a3d051b-72ef-4a5d-8a48-eb0dbb960b56
>         Total devices 3 FS bytes used 6.55TiB
>         devid    1 size 3.64TiB used 1.62TiB path /dev/bcache1
>         devid    2 size 7.28TiB used 5.21TiB path /dev/bcache0
>         devid    3 size 12.73TiB used 6.80TiB path /dev/bcache2
> 
> I have tried booting using a live ISO with 5.8.0 kernel and btrfs v5.6.1
> from http://defender.exton.net/.
> After booting tried mounting the bcache using the same command as above.
> The only message in the console was "Killed".
> /dev/kmsg on the other hand lists messages very similar to the ones I've
> seen in the initramfs environment: https://pastebin.com/Vhy072Mx

It looks like there is a chance to recover, as there is a rootbackup
with newer generation.

While tree-checker is rejecting the newer generation one.

The kernel panic is caused by some corner error handling with root
backups cleanups.
We need to fix it anyway.

In this case, I guess "btrfs ins dump-super -fFa" output would help to
show if it's possible to recover.

Anyway, something looks strange.

The backup roots have a newer generation while the super block is still
old doesn't look correct at all.

Thanks,
Qu
> 
> P.S. Please CC me, as I am not subscribed.
> 
> Thank you,
> Illia Bobyr
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]