On 2018/11/2 下午10:30, M. Klingmann wrote:

On 31.10.2018 at 01:03 Qu Wenruo wrote:

quoted

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

quoted

Thanks,
Qu

Thank you for your quick response and help.