On 2021/8/12 上午6:34, Konstantin Svist wrote:

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

quoted

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?

Then it will be more complex and I can't ensure any good result.

Firstly you need to find an older root tree:

# btrfs ins dump-super -f /dev/sdb3 | grep backup_tree_root
                 backup_tree_root:       30687232        gen: 2317
  level: 0
                 backup_tree_root:       30834688        gen: 2318
  level: 0
                 backup_tree_root:       30408704        gen: 2319
  level: 0
                 backup_tree_root:       31031296        gen: 2316
  level: 0

Then try the bytenr in their reverse generation order in btrfs ins
dump-tree:
(The latest one should be the current root, thus you can skip it)

# btrfs ins dump-tree -b 30834688 /dev/sdb3 | grep "(257 ROOT_ITEM" -A 5

Then grab the bytenr of the subvolume 257, then pass the bytenr to
btrfs-restore:

# btrfs-restore -f <bytenr> /dev/sdb3 <restore_path>

The chance is already pretty low, good luck.

Thanks,
Qu

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