search

kdave / btrfs-progs

Development of userspace BTRFS tools
GNU General Public License v2.0
527 stars 239 forks source link

Unclear if files have been lost after partition becoming unmountable #780

Closed Pacarius closed 2 months ago

Pacarius commented 2 months ago

So, just today, after rebooting my pc, the btrfs partition has become unmountable entirely. I'm mainly wondering if my data has been completely erased. Thanks in advance.

running btrfsck on partition: sudo btrfsck /dev/sde3 Opening filesystem to check... checksum verify failed on 17273913344 wanted 0x00000000 found 0xb6bde3e4 checksum verify failed on 17273913344 wanted 0x00000000 found 0xb6bde3e4 bad tree block 17273913344, bytenr mismatch, want=17273913344, have=0 ERROR: cannot read chunk root ERROR: cannot open file system

Running inspect-internal dump-super on partition: sudo btrfs inspect-internal dump-super /dev/sde3 superblock: bytenr=65536, device=/dev/sde3

csum_type 0 (crc32c) csum_size 4 csum 0x211a4925 [match] bytenr 65536 flags 0x1 ( WRITTEN ) magic _BHRfS_M [match] fsid dfb1fee7-2bdb-4573-a172-0b2d7b1315c7 metadata_uuid dfb1fee7-2bdb-4573-a172-0b2d7b1315c7 label arch_os generation 11223 root 90237419520 sys_array_size 194 chunk_root_generation 11219 root_level 0 chunk_root 17273913344 chunk_root_level 1 log_root 0 log_root_transid 0 log_root_level 0 total_bytes 1022060658688 bytes_used 434599038976 sectorsize 4096 nodesize 16384 leafsize (deprecated) 16384 stripesize 4096 root_dir 6 num_devices 1 compat_flags 0x0 compat_ro_flags 0x3 ( FREE_SPACE_TREE | FREE_SPACE_TREE_VALID ) incompat_flags 0x371 ( MIXED_BACKREF | COMPRESS_ZSTD | BIG_METADATA | EXTENDED_IREF | SKINNY_METADATA | NO_HOLES ) cache_generation 11223 uuid_tree_generation 5387 dev_item.uuid fcad0d22-5eb1-4324-8654-3019aeee1a56 dev_item.fsid dfb1fee7-2bdb-4573-a172-0b2d7b1315c7 [match] dev_item.type 0 dev_item.total_bytes 1022060658688 dev_item.bytes_used 659396251648 dev_item.io_align 4096 dev_item.io_width 4096 dev_item.sector_size 4096 dev_item.devid 1 dev_item.dev_group 0 dev_item.seek_speed 0 dev_item.bandwidth 0 dev_item.generation 0

adam900710 commented 2 months ago

checksum verify failed on 17273913344 wanted 0x00000000 found 0xb6bde3e4

This means the tree block is fully wiped.

Are you using discard mount option? And what's the model for the disk?

Otherwise you can try btrfs rescue chunk-recover to see if a chunk tree can be recovered. But considering a critical tree block is just being fully wiped unexpectedly, I doubt if it's only chunk tree got corrupted.

Pacarius commented 2 months ago

I am not using the discard mount option, and the disk is a Kingston sc 3000 1 tb. Chunk-recover did not work.

adam900710 commented 2 months ago

And no unexpected power loss?

Then it really looks like the disk is not properly doing its writeback/flush.

Anyway this means it would be a total fs loss, feel free to use btrfs rescue chunk-recovery to take a try.

Pacarius commented 2 months ago

There may have been something akin to a sudden power loss (system froze up and did a hard reboot), btrfs rescue chunk-recovery failed and I forgot the error message; something along the line of failed to insert extend. Will try to get the error message once I'm back home.

adam900710 commented 2 months ago

In that case, I'm not confident about that drive.

Even for a sudden power loss, previous committed transaction should reach disk by the FLUSH command, along with the corresponding super block. And since you're not using discard, those older tree blocks should not be wiped anyway.

You can also try "btrfs check -b" to see if it can makes any difference, which would try the backup roots (and hopefully the backup chunk tree root is still good).

Pacarius commented 2 months ago

btrfs rescue chunk-recover now shows

ERROR: duplicate entry in cache start 94522966016 size 1073741824

btrfs check -b returns the same result as btrfsck