On 8/11/21 14:51, Qu Wenruo wrote:

On 2021/8/12 上午3:33, Konstantin Svist wrote:

quoted

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

quoted

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

Then it means, the tree blocks of that subvolume is corrupted, thus no
way to read that subvolume, unfortunately.

Thanks,
Qu

Shouldn't there be an earlier generation of this subvolume's tree block
somewhere on the disk? Would all of them have gotten overwritten already?

Any hope for any individual files, if not for subvolume?