On Tue, Jul 21, 2020 at 11:35 AM Graham Cobb <g.btrfs@xxxxxxxxxxx> wrote: > > On 21/07/2020 18:16, David Sterba wrote: > > On Tue, Jul 21, 2020 at 04:56:55PM +0100, Graham Cobb wrote: > >> If it means "only filesystem" that doesn't make sense to me - the whole > >> thing is the filesystem. I guess "only data" might be more meaningful > >> but if the aim is to turn on as much recovery as possible to help the > >> user to save their data then why not just say so? > >> > >> Something like "rescue=max", "rescue=recoverymode", "rescue=dataonly", > >> "rescue=ignoreallerrors" or "rescue=emergency" might be more meaningful. > > > > From user perspective the option should have a high level semantics, > > like you suggest above. We should add individual options to try to work > > around specific damage if not just for testing purposes, having more > > flexibility is a good thing. > > I would also prefer not to have checksum checking disabled by this "try > harder" option. I would imagine turning on "ignore whatever checks you > can to get me my data back mode", retrieving all the readable data with > valid checksums and getting errors for things which cannot be verified. > Then I would make a decision as to whether to enable another option to > even provide files which the filesystem cannot guarantee have not been > corrupted because it can't check checksums. Even if that is all the > files (because the checksum tree is destroyed) I should have to make an > explicit acknowledgement that I want that. It would be nice if this rescue=all mount option, continues to spit out noisy and scary warnings about the problems encountered. Including corrupt files with path to the corrupt file. Just avoid face planting. I assume rescue=all implies ro (possibly also nologreplay). -- Chris Murphy
