On 2018/11/2 下午10:30, M. Klingmann wrote: > > On 31.10.2018 at 01:03 Qu Wenruo wrote: >> My plan for such recovery is: >> >> 1) btrfs ins dump-super to make sure system chunk array is valid >> 2) btrfs-find-root to find any valid chunk tree blocks >> 3) pass that chunk tree bytenr to btrfs-restore >> Unfortunately, btrfs-restore doesn't support specifying chunk root >> yet. But it's pretty easy to add such support. >> >> So, please provide the "btrfs ins dump-super -Ffa" output to start with. > Following your plan, I did 1) and 2). > As 2) failed (see below), is there anything I can do to find the tree > bytenr to supply btrfs-restore with it? > > 1) Here's the output given by "btrfs-show-super -Ffa": > > superblock: bytenr=65536, device=sdcard.iso > --------------------------------------------------------- > csum 0xb8e15dd7 [match] > bytenr 65536 > flags 0x1 > ( WRITTEN ) > magic _BHRfS_M [match] > fsid 4235aa4f-7721-4e73-97f0-7fe0e9a3ce9c > label > generation 1757933 > root 889143296 > sys_array_size 226 > chunk_root_generation 932006 > root_level 0 > chunk_root 20987904 > chunk_root_level 0 > log_root 890109952 > log_root_transid 0 > log_root_level 0 > total_bytes 30666653696 > bytes_used 16937803776 > sectorsize 4096 > nodesize 16384 > leafsize 16384 > stripesize 4096 > root_dir 6 > num_devices 1 > compat_flags 0x0 > compat_ro_flags 0x0 > incompat_flags 0x61 > ( MIXED_BACKREF | > BIG_METADATA | > EXTENDED_IREF ) > csum_type 0 > csum_size 4 > cache_generation 1757933 > uuid_tree_generation 149 > dev_item.uuid 90185cf6-b937-49bb-b191-91d08677ee22 > dev_item.fsid 4235aa4f-7721-4e73-97f0-7fe0e9a3ce9c [match] > dev_item.type 0 > dev_item.total_bytes 30666653696 > dev_item.bytes_used 30666653696 > 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 0) > chunk length 4194304 owner 2 stripe_len 65536 > type SYSTEM num_stripes 1 > stripe 0 devid 1 offset 0 > dev uuid: 90185cf6-b937-49bb-b191-91d08677ee22 > item 1 key (FIRST_CHUNK_TREE CHUNK_ITEM 20971520) > chunk length 8388608 owner 2 stripe_len 65536 > type SYSTEM|DUP num_stripes 2 This chunk looks pretty OK. And it's DUP, so it improves the possibility to recover. > stripe 0 devid 1 offset 20971520 > dev uuid: 90185cf6-b937-49bb-b191-91d08677ee22 > stripe 1 devid 1 offset 29360128 > dev uuid: 90185cf6-b937-49bb-b191-91d08677ee22 > backup_roots[4]: > backup 0: > backup_tree_root: 889143296 gen: 1757933 level: 0 > backup_chunk_root: 20987904 gen: 932006 level: 0 > backup_extent_root: 888881152 gen: 1757933 level: 2 > backup_fs_root: 889716736 gen: 1757934 level: 2 > backup_dev_root: 307560448 gen: 1673227 level: 0 > backup_csum_root: 887898112 gen: 1757934 level: 2 > backup_total_bytes: 30666653696 > backup_bytes_used: 16937803776 > backup_num_devices: 1 > > backup 1: > backup_tree_root: 882311168 gen: 1757930 level: 0 > backup_chunk_root: 20987904 gen: 932006 level: 0 > backup_extent_root: 879738880 gen: 1757931 level: 2 > backup_fs_root: 883097600 gen: 1757931 level: 2 > backup_dev_root: 307560448 gen: 1673227 level: 0 > backup_csum_root: 883212288 gen: 1757931 level: 2 > backup_total_bytes: 30666653696 > backup_bytes_used: 16943640576 > backup_num_devices: 1 > > backup 2: > backup_tree_root: 881082368 gen: 1757931 level: 0 > backup_chunk_root: 20987904 gen: 932006 level: 0 > backup_extent_root: 879738880 gen: 1757931 level: 2 > backup_fs_root: 883654656 gen: 1757932 level: 2 > backup_dev_root: 307560448 gen: 1673227 level: 0 > backup_csum_root: 883703808 gen: 1757932 level: 2 > backup_total_bytes: 30666653696 > backup_bytes_used: 16943722496 > backup_num_devices: 1 > > backup 3: > backup_tree_root: 887865344 gen: 1757932 level: 0 > backup_chunk_root: 20987904 gen: 932006 level: 0 > backup_extent_root: 888881152 gen: 1757933 level: 2 > backup_fs_root: 888750080 gen: 1757933 level: 2 > backup_dev_root: 307560448 gen: 1673227 level: 0 > backup_csum_root: 888832000 gen: 1757933 level: 2 > backup_total_bytes: 30666653696 > backup_bytes_used: 16937803776 > backup_num_devices: 1 [snip] > 2) "btrfs-find-root" yields "Couldn't read chunk root; Open ctree failed". It's not plain "btrfs-find-root" but "btrfs-find-root -o 5". And you should use btrfs-progs v4.17.1, not the old v4.4. The ability to continue search even if chunk tree get corrupted is added in v4.5, and I strongly recommend to use latest (v4.17.1) for a lot of fixes and extra debug output. If you can't find any handy way to update btrfs-progs, you could use Archlinux iso as a rescue OS to use the latest btrfs-progs. For 3), I could easily add such feature btrfs-restore, or just use manually patching your superblock to continue. So as soon as your "btrfs-find-root -o 5" gets some valid output, I could continue the work. Thanks, Qu > >> Thanks, >> Qu > > Thank you for your quick response and help. >
Attachment:
signature.asc
Description: OpenPGP digital signature
