Hopefully the long term solution is kernel 5.10's mount -o ro,rescue=all will allow normal navigation and copy out of a corrupt file, complain about csum errors but not EIO?

Short term, we probably need a how to do this in 'btrfs restore'. Because I've already gotten this question as a hypothetical, as folks realize most application give up on EIO, effectively meaning their file is stuck. Somehow we need a program that will tolerantly read the file without giving up.

Today is painful to just get the file out of a file system that isn't even damaged.

Actual steps needed:

1. Reboot to dracut or LiveCD (because restore won't work on a mounted fs)
2. btrfs restore --list-roots
3. btrfs insp dump-t -t 1 /dev/whatever | grep -A1 'ROOT_REF rootid' (because the previous command doesn't list the subvolume names)
   https://github.com/kdave/btrfs-progs/issues/289
4. btrfs restore -i -v -r 265 /dev/whatever --path-regex ^/(|home(|/username(|/Desktop(|/.*))))$ /path/to/restore/to/ (because all problems are solved by regex but now you have to use regex therefore the file could not possibly be worth restoring)

Requested steps:

• Eliminate steps 2 and 3 with a new flag for restore, --subvol which accepts the subvol name, i.e. home.
• new flag for restore --path-file that will accept the path to the bad file that the kernel spits out upon checksum error; figure out the regex internally.

Or maybe someone knows of a regex calculator? I can't find one that gives a regex that restore will eat. Maybe there's a regex bug here or possibly I'm being mislead by the man page's regex example. Or maybe I just need to drink a lot of whiskey before doing regex...