0

I have a 120 GB Samsung SSD which I setup as a LUKS volume with btrfs in Xubuntu 18.04 which has been running fine until I tried booting this afternoon and discovered lines like this in dmesg when it attempts to mount (after the LUKS passphrase has been accepted):

[ 8023.426359] BTRFS info (device dm-0): disk space caching is enabled
[ 8023.426361] BTRFS info (device dm-0): has skinny extents
[ 8023.427820] BTRFS error (device dm-0): bad tree block start, want 120516247552 have 17642829462275766793
[ 8023.427828] BTRFS warning (device dm-0): failed to read tree root
[ 8023.459232] BTRFS error (device dm-0): open_ctree failed

If that "want" value is supposed to be a byte offset it seems way beyond any sane amount. I booted to an Ubuntu 19.04 flash drive and tried doing a rescue chunk-recover which reported 111 recoverable chunks and "Chunk tree recovered successfully", but it didn't have any impact on the problem. I ran the chunk-recover process again and it produced output identical to the first run so it seems to not be doing anything.

I tried doing a rescue super-recover just to see what happened and it reported 2 superblocks which were already in good condition and it didn't take any action.

At this point I backed up the disk with dd to a file on some working storage. I know my data (or at least some of it) is still there, since I can see the contents of plain text files if I page through an xxd dump of the image.

I tried doing check --repair which I understand is a last resort, but that didn't get off the ground either, with an error similar to the mount failure in dmesg:

enabling repair mode
Opening filesystem to check...
checksum verify failed on 120516247552 found 4D050B32 wanted 0EB4D74B
checksum verify failed on 120516247552 found 4D050B32 wanted 0EB4D74B
bad tree block 120516247552, bytenr mismatch, want=120516247552, have=17642829462275766793
Couldn't read tree root
ERROR: cannot open file system

I'm pretty sure this isn't a duplicate of BTRFS bad tree block start

EDIT: I tried using inspect-internal dump-tree -b ... pointing it at various locations aligned with the sector size and all of them generate a checksum mismatch error, which I noticed check --repair and other commands complained about when attempting to read the root tree at 120516247552. Is that a symptom of some particular problem when checksums fail everywhere on the disk? (Failing hardware?) Just to reiterate, I was able to make an image of the disk's contents with dd and I can see the plaintext data in there, it's not all garbage, so the idea that the disk isn't able to return any valid data seems unlikely.

  • Have you already asked for assistance on the BTRFS mailing list? That's probably the best place for your question. – Emmanuel Rosa May 9 at 10:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.