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
> 
> 

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to