On 2018/10/7 下午2:10, evan d wrote: >> Please try "btrfs ins dump-super -fFa" on these two disks. >> >> If it's only the primary superblock corrupted, the backup should be good. >> >> If backup is also corrupted, either it has some offset or the whole data >> is corrupted. > > # btrfs ins dump-super -fFa /dev/sdb > superblock: bytenr=65536, device=/dev/sdb > --------------------------------------------------------- > csum_type 0 (crc32c) > csum_size 4 > csum 0x00000000 [DON'T MATCH] > bytenr 0 > flags 0x0 > magic ........ [DON'T MATCH] [snip] > superblock: bytenr=274877906944, device=/dev/sdb > --------------------------------------------------------- > csum_type 26294 (INVALID) > csum_size 32 > csum 0x05401fa3a3e8cd64075ce9fdbb9e60a01d58061a3cff3bc0235d18912ab755a2 > [UNKNOWN CSUM TYPE OR SIZE] > bytenr 7401042280310172376 > flags 0x5a8a759265673a05 > ( WRITTEN | > METADUMP | > unknown flag: 0x5a8a759065673a04 ) > magic .~...6.. [DON'T MATCH] [snip]
None of your super blocks has correct magic. This means either your whole disk get corrupted, or something introduced some offset. Please try the following commands to dump more data around super blocks, so we could be able to find the possible offset: # dd if=/dev/sdb of=possible_sb_range.raw bs=1M count=128 # grep -obUaP "\x5F\x42\x48\x52\x66\x53\x5F\x4D" possible_sb_range. For a valid btrfs without any offset, the result should look like: 65600:_BHRfS_M 67108928:_BHRfS_M If your result doesn't look like this but still has two similar hits, then you could calculate the offset, and use dm-linear to remap the disk and try to recover the fs. Thanks, Qu
signature.asc
Description: OpenPGP digital signature
