On 8/10/21 22:49, Qu Wenruo wrote:

On 2021/8/11 下午1:34, Konstantin Svist wrote:

quoted

On 8/10/21 22:24, Qu Wenruo wrote:

quoted

On 2021/8/11 下午1:22, Konstantin Svist wrote:

quoted

On 8/10/21 16:54, Qu Wenruo wrote:

quoted

Oh, that btrfs-map-logical is requiring unnecessary trees to
continue.

Can you re-compile btrfs-progs with the attached patch?
Then the re-compiled btrfs-map-logical should work without problem.

Awesome, that worked to map the sector & mount the partition.. but I
still can't access subvol_root, where the recent data is:

Is subvol_root a subvolume?

If so, you can try to mount the subvolume using subvolume id.

But in that case, it would be not much different than using
btrfs-restore with "-r" option.

Yes it is.

# mount -oro,rescue=all,subvol=subvol_root /dev/sdb3 /mnt/
mount: /mnt: can't read superblock on /dev/sdb3.

I mean using subvolid=<number>

Using subvol= will still trigger the same path lookup code and get
aborted by the IO error.

To get the number, I guess the regular tools are not helpful.

You may want to manually exam the root tree:

# btrfs ins dump-tree -t root <device>

Then look for the keys like (<number> ROOT_ITEM <0 or number>), and try
passing the first number to "subvolid=" option. 

This works (and numbers seem to be the same as from dump-tree):
# mount -oro,rescue=all /dev/sdb3 /mnt/
# btrfs su li /mnt/
ID 257 gen 166932 top level 5 path subvol_root
ID 258 gen 56693 top level 5 path subvol_snapshots
ID 498 gen 56479 top level 258 path subvol_snapshots/29/snapshot
ID 499 gen 56642 top level 258 path subvol_snapshots/30/snapshot
ID 500 gen 56691 top level 258 path subvol_snapshots/31/snapshot

This also works (not what I want):
# mount -oro,rescue=all,subvol=subvol_snapshots /dev/sdb3 /mnt/


But this doesn't:

# mount -oro,rescue=all,subvolid=257 /dev/sdb3 /mnt/
mount: /mnt: can't read superblock on /dev/sdb3.

dmesg:
BTRFS error (device sdb3): bad tree block start, want 920748032 have 0