Hi,
I have a filesystem that appears to have lost it's data. I believe the ATA interface on the
host has failed, which has lead to this problem. It would be nice to recover the data if
possible. Prior to realizing the ATA bus was the issue I had two other BTRFS filesystems
connected, all of which were repaired by connecting to another ATA bus then scrubbing.
This particular filesystem has no subvolume snapshots, though I have been using snapper on
other filesystems to manage this.
The filesystem can be mounted without issue, but when I try to scrub it aborts immediately
with the following status. Before disconnecting I believe the filesystem was being
automatically remounted read-only when writes were attempted, though I haven't confirmed this.
$ sudo btrfs scrub status /mnt/crypt-timemachine
scrub status for a09ae23f-f5b9-4ff4-a29a-d2fd81c6d450
scrub started at Mon May 4 14:50:42 2020 and was aborted after 00:00:00
total bytes scrubbed: 264.00KiB with 0 errors
In the kernel logs I see:
kernel: BTRFS critical (device dm-4): unable to find logical 39209762816 length 4096
kernel: BTRFS critical (device dm-4): unable to find logical 39209762816 length 4096
kernel: BTRFS critical (device dm-4): unable to find logical 39209762816 length 16384
The output of btrfs check:
$ sudo btrfs check /dev/mapper/crypt-timemachine
Checking filesystem on /dev/mapper/crypt-timemachine
UUID: a09ae23f-f5b9-4ff4-a29a-d2fd81c6d450
checking extents
Couldn't map the block 39209762816
Invalid mapping for 39209762816-39209779200, got 588439879680-588976750592
Couldn't map the block 39209762816
bytenr mismatch, want=39209762816, have=0
ref mismatch on [39209762816 16384] extent item 0, found 1
tree backref 39209762816 parent 7 root 7 not found in extent tree
backpointer mismatch on [39209762816 16384]
owner ref check failed [39209762816 16384]
ref mismatch on [588965576704 16384] extent item 1, found 0
backref 588965576704 root 7 not referenced back 0x55ccdfad6660
incorrect global backref count on 588965576704 found 1 wanted 0
backpointer mismatch on [588965576704 16384]
owner ref check failed [588965576704 16384]
ERROR: errors found in extent allocation tree or chunk allocation
checking free space cache
checking fs roots
checking csums
Couldn't map the block 39209762816
Invalid mapping for 39209762816-39209779200, got 588439879680-588976750592
Couldn't map the block 39209762816
bytenr mismatch, want=39209762816, have=0
Error going to next leaf -5
checking root refs
found 712704 bytes used, error(s) found
total csum bytes: 8
total tree bytes: 147456
total fs tree bytes: 32768
total extent tree bytes: 16384
btree space waste bytes: 132656
file data blocks allocated: 532480
referenced 532480
SMART output for the disk doesn't suggest any issues with the disk itself, i.e.
Offline_Uncorrectable, UDMA_CRC_Error_Count, Reallocated_Event_Count,
Current_Pending_Sector, Reallocated_Sector_Ct, Seek_Error_Rate, are all 0. Extended offline
tests are run regularly and have all completed without error.
I've tried to scrub on multiple hosts with varying kernels and btrfs-progs
1. Original host was Debian Buster on a backports kernel:
5.4.0-0.bpo.4-amd64 #1 SMP Debian 5.4.19-1~bpo10+1 (2020-03-09) x86_64 GNU/Linux
Started with stock btrfs-progs 4.20.1-2, then tried the package from backports,
btrfs-progs 5.2.1-1~bpo10+1
2. Second host was Ubuntu 18.04 with a mainline kernel:
5.6.7-050607-generic #202004230933 SMP Thu Apr 23 09:35:28 UTC 2020 x86_64 GNU/Linux
Only tried stock btrfs-progs here: 4.15.1-1build1
Disk is connected via a USB to SATA adapter.
3. Third system is a stocket Ubuntu 18.04
4.15.0-99-generic #100-Ubuntu SMP Wed Apr 22 20:32:56 UTC 2020 x86_64 GNU/Linux
With btrfs-progs 4.15.1-1build1.
At this point is there any hope of recovering the data? If not, is it worth trying to do a
repair with `btrfs check`, or anything else? Or should I just go ahead and re-format the disk?
Any help is much appreciated.
Thanks,
Jinn
