Hi Qu, attached is the binary super block as requested.
Thank you, Ken On 03/05/2018 09:07 PM, Qu Wenruo wrote: > > On 2018年03月06日 09:51, Ken Swenson wrote: >> Hello, >> >> Somehow it appears the csum_type on my btrfs file system got corrupted. >> I cannot mount the system in recovery or read only. btrfs check just >> returns "ERROR: unsupported checksum algorithm 35355" as well as btrfs >> recover. The only command I was able to successfully run was btrfs >> inspect-internal dump-super, which I've pasted the output at the end of >> this message. >> >> Requested information from the wiki: >> Linux 4.15.7-1-ARCH #1 SMP PREEMPT Wed Feb 28 19:01:57 UTC 2018 x86_64 >> GNU/Linux >> btrfs-progs v4.15.1 >> btrfs fi show: ERROR: unsupported checksum algorithm 35355 ERROR: cannot >> scan /dev/mapper/x: Input/output error >> >> dmesg: >> [ 11.232399] Btrfs loaded, crc32c=crc32c-intel >> [ 11.233229] BTRFS: device fsid 513f07e1-08be-4d94-a55c-11c6251f6c2f >> devid 1 transid 7777 /dev/dm-2 >> [ 488.372891] BTRFS error (device dm-2): unsupported checksum algorithm >> 35355 >> [ 488.372894] BTRFS error (device dm-2): superblock checksum mismatch >> [ 488.384902] BTRFS error (device dm-2): open_ctree failed >> >> Is there anything I can do to recovery from this or am I out of luck? To >> give some background the disk was working fine until I upgraded to >> Kernel 4.15.7 and rebooted. >> >> superblock: bytenr=65536, device=/dev/mapper/x >> --------------------------------------------------------- >> csum_type 35355 (INVALID) > This is obviously corrupted. > > Btrfs only supports csum_type 0 (CRC32) yet. > > And the value seems to be some garbage. > >> csum_size 32 > So is the csum size. > >> csum >> 0xf0dbeddd00000000000000000000000000000000000000000000000000000000 [match] > Surprised to see the csum even matched. > >> bytenr 65536 >> flags 0x1 >> ( WRITTEN ) >> magic _BHRfS_M [match] >> fsid 513f07e1-08be-4d94-a55c-11c6251f6c2f >> label >> generation 7777 >> root 186466304 >> sys_array_size 129 >> chunk_root_generation 7450 >> root_level 1 >> chunk_root 21004288 >> chunk_root_level 1 >> log_root 0 >> log_root_transid 0 >> log_root_level 0 >> total_bytes 5000947523584 >> bytes_used 420849201152 >> sectorsize 4096 >> nodesize 16384 >> leafsize (deprecated) 16384 >> stripesize 4096 >> root_dir 6 >> num_devices 1 >> compat_flags 0x0 >> compat_ro_flags 0x0 >> incompat_flags 0x176d200000000169 >> ( MIXED_BACKREF | >> COMPRESS_LZO | >> BIG_METADATA | >> EXTENDED_IREF | >> SKINNY_METADATA | >> unknown flag: 0x176d200000000000 ) > And unknown flags also exists. > > And according to later output, all backup super blocks have the same > corruption while csum still matches. > > I'm wondering if the memory is corrupted. > > It's possible to manually modify the superblock to a valid status. > As all the corruption is obvious, but I'm not 100% sure if there is > other corruption. > > Please provide the binary superblock dump by: > > dd if=<device> bs=1 count=4K skip=64K of=super_copy > > Thanks, > Qu > >> cache_generation 7777 >> uuid_tree_generation 7777 >> dev_item.uuid 880c692f-5270-4c7a-908d-8b3956fb3790 >> dev_item.fsid 513f07e1-08be-4d94-a55c-11c6251f6c2f [match] >> dev_item.type 0 >> dev_item.total_bytes 5000947523584 >> dev_item.bytes_used 457439182848 >> 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 >> sys_chunk_array[2048]: >> item 0 key (FIRST_CHUNK_TREE CHUNK_ITEM 20971520) >> length 8388608 owner 2 stripe_len 65536 type SYSTEM|DUP >> io_align 65536 io_width 65536 sector_size 4096 >> num_stripes 2 sub_stripes 0 >> stripe 0 devid 1 offset 20971520 >> dev_uuid 880c692f-5270-4c7a-908d-8b3956fb3790 >> stripe 1 devid 1 offset 29360128 >> dev_uuid 880c692f-5270-4c7a-908d-8b3956fb3790 >> backup_roots[4]: >> backup 0: >> backup_tree_root: 181174272 gen: 7774 level: 1 >> backup_chunk_root: 21004288 gen: 7450 level: 1 >> backup_extent_root: 181190656 gen: 7774 level: 2 >> backup_fs_root: 809828352 gen: 6404 level: 0 >> backup_dev_root: 93585408 gen: 7631 level: 1 >> backup_csum_root: 181862400 gen: 7774 level: 2 >> backup_total_bytes: 5000947523584 >> backup_bytes_used: 420849201152 >> backup_num_devices: 1 >> >> backup 1: >> backup_tree_root: 183828480 gen: 7775 level: 1 >> backup_chunk_root: 21004288 gen: 7450 level: 1 >> backup_extent_root: 183320576 gen: 7775 level: 2 >> backup_fs_root: 809828352 gen: 6404 level: 0 >> backup_dev_root: 183975936 gen: 7775 level: 1 >> backup_csum_root: 185761792 gen: 7775 level: 2 >> backup_total_bytes: 5000947523584 >> backup_bytes_used: 420849201152 >> backup_num_devices: 1 >> >> backup 2: >> backup_tree_root: 186810368 gen: 7776 level: 1 >> backup_chunk_root: 21004288 gen: 7450 level: 1 >> backup_extent_root: 186613760 gen: 7776 level: 2 >> backup_fs_root: 809828352 gen: 6404 level: 0 >> backup_dev_root: 183975936 gen: 7775 level: 1 >> backup_csum_root: 187056128 gen: 7776 level: 2 >> backup_total_bytes: 5000947523584 >> backup_bytes_used: 420849201152 >> backup_num_devices: 1 >> >> backup 3: >> backup_tree_root: 186466304 gen: 7777 level: 1 >> backup_chunk_root: 21004288 gen: 7450 level: 1 >> backup_extent_root: 187908096 gen: 7777 level: 2 >> backup_fs_root: 809828352 gen: 6404 level: 0 >> backup_dev_root: 183975936 gen: 7775 level: 1 >> backup_csum_root: 188071936 gen: 7777 level: 2 >> backup_total_bytes: 5000947523584 >> backup_bytes_used: 420849201152 >> backup_num_devices: 1 >> >>
super_copy
Description: Binary data
signature.asc
Description: OpenPGP digital signature
