Bad tree block start, can't mount but data seems intact

Bad tree block start, can't mount but data seems intact

[btrfs.5.gumpish]

Hello. I have a btrfs partition which I'd been using for several
months with no problems until last week when it suddenly stopped
mounting.

It would be a pleasant surprise if there was a relatively painless way
to restore the drive to normal functionality, or at least recover any
files which might be intact, so I'm hoping someone here might take an
interest.

It may be worth noting that the partition is an SSD encrypted with
luks, though I experience no errors when mapping the partition, and I
have been able to dump the decrypted content of the partition and the
text of just about every plaintext file I can think of seems to be
perfectly intact.

Here's the required information for support requests, per the wiki
page about the mailing list, although these commands are being run in
a fresh installation of the same OS I had been using on the broken
partition (Xubuntu 18.04):

$ uname -a
Linux foo 4.18.0-18-generic #19~18.04.1-Ubuntu SMP Fri Apr 5 10:22:13
UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

$ btrfs --version
btrfs-progs v4.15.1

$ sudo btrfs fi show
Label: none  uuid: cc6d8bac-f4f2-417c-bc59-ef4841617697
Total devices 1 FS bytes used 21.93GiB
devid    1 size 137.84GiB used 24.02GiB path /dev/mapper/sdc2_crypt

Label: none  uuid: 1d09eb6e-841e-465d-8c1d-75076b1c4b9a
Total devices 1 FS bytes used 83.26GiB
devid    1 size 110.57GiB used 107.57GiB path /dev/mapper/borked

Partition doesn't mount, can't run btrfs fi df /path/to/mount/point

Here's the output from dmesg when attempting to mount:

[ 4985.360439] BTRFS: device fsid 1d09eb6e-841e-465d-8c1d-75076b1c4b9a
devid 1 transid 344552 /dev/dm-1
[ 4990.973466] BTRFS info (device dm-1): disk space caching is enabled
[ 4990.973467] BTRFS info (device dm-1): has skinny extents
[ 4990.979229] BTRFS error (device dm-1): bad tree block start
17642829462275766793 120516247552
[ 4990.979237] BTRFS warning (device dm-1): failed to read tree root
[ 4991.008004] BTRFS error (device dm-1): open_ctree failed


/dev/mapper/borked (aka /dev/dm-1) is the drive in question. I'm
curious about the discrepancy between "FS bytes used" and the bytes
used on the following line. I don't have extensive experience with CoW
filesystems or troubleshooting filesystems in general so it's all
quite mysterious...

Since the drive only has ~110GiB capacity, it's certianly
understandable that 17642829462275766793 isn't a valid byte address.

I've followed some guidance from the web but haven't had any luck.
Here's what I've tried so far:

I tried a 'rescue chunk-recover', which reported 111 recoverable
blocks (i.e. 100% of the drive, zero unrecoverable chunks) and "Chunk
tree recovered successfully". Unfortunately the "bad tree block start"
error during mount did not change at all and the partition still would
not mount. I ran the chunk-recover process a second time and it
produced output identical to the first run so it seems to not be doing
anything. Maybe there's an undocumented flag you have to provide in
order for the tool to actually write changes to disk?

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.

After dumping the contents of the drive with dd, I tried 'check
--repair', but it immediately terminated with the following output:

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 tried using 'inspect-internal dump-tree -b ...' pointing it at
various locations aligned with the sector size and all of them
generate a checksum verification failure, similar to what's shown in
the output above. It seems weird that every single block would be
generating an invalid checksum when there's so much perfectly intact
data on the disk.

'restore -v ...' yields the following:

checksum verify failed on 120516247552 found 4D050B32 wanted 0EB4D74B
checksum verify failed on 120516247552 found 4D050B32 wanted 0EB4D74B
bytenr mismatch, want=120516247552, have=17642829462275766793
Couldn't read tree root
Could not open root, trying backup super
checksum verify failed on 120516247552 found 4D050B32 wanted 0EB4D74B
checksum verify failed on 120516247552 found 4D050B32 wanted 0EB4D74B
bytenr mismatch, want=120516247552, have=17642829462275766793
Couldn't read tree root
Could not open root, trying backup super
ERROR: superblock bytenr 274877906944 is larger than device size 118726066176
Could not open root, trying backup super

'mount -t btrfs -o ro,usebackuproot' produces the following:

[ 7808.542029] BTRFS info (device dm-1): trying to use backup root at mount time
[ 7808.542030] BTRFS info (device dm-1): disk space caching is enabled
[ 7808.542031] BTRFS info (device dm-1): has skinny extents
[ 7808.542797] BTRFS error (device dm-1): bad tree block start
17642829462275766793 120516247552
[ 7808.542801] BTRFS warning (device dm-1): failed to read tree root
[ 7808.542933] BTRFS error (device dm-1): bad tree block start
17642829462275766793 120516247552
[ 7808.542936] BTRFS warning (device dm-1): failed to read tree root
[ 7808.547606] BTRFS error (device dm-1): bad tree block start
16167207305002578331 120515936256
[ 7808.547610] BTRFS warning (device dm-1): failed to read tree root
[ 7808.547692] BTRFS error (device dm-1): bad tree block start
11402994761705913451 120516100096
[ 7808.547695] BTRFS warning (device dm-1): failed to read tree root
[ 7808.547777] BTRFS error (device dm-1): bad tree block start
1442009718635089341 120514871296
[ 7808.547781] BTRFS warning (device dm-1): failed to read tree root
[ 7808.556796] BTRFS error (device dm-1): open_ctree failed

Thanks for reading.