Here is the fixed superblock. csum type and incompat flags get fixed.
I'm not sure if they are the only problems, but I strongly recommend to run btrfs check before mount. Thanks, Qu On 2018年03月06日 10:22, Ken Swenson wrote: > 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
