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.