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:
signature.asc
Description: OpenPGP digital signature
