On Wed, Jul 01, 2020 at 10:44:38AM -0400, Josef Bacik wrote: > One of the things that came up consistently in talking with Fedora about > switching to btrfs as default is that btrfs is particularly vulnerable > to metadata corruption. If any of the core global roots are corrupted, > the fs is unmountable and fsck can't usually do anything for you without > some special options. > > Qu addressed this sort of with rescue=skipbg, but that's poorly named as > what it really does is just allow you to operate without an extent root. > However there are a lot of other roots, and I'd rather not have to do > > mount -o rescue=skipbg,rescue=nocsum,rescue=nofreespacetree,rescue=blah > > Instead take his original idea and modify it so it just works for > everything. Turn it into rescue=onlyfs, and then any major root we fail > to read just gets left empty and we carry on. > > Obviously if the fs roots are screwed then the user is in trouble, but > otherwise this makes it much easier to pull stuff off the disk without > needing our special rescue tools. I tested this with my TEST_DEV that > had a bunch of data on it by corrupting the csum tree and then reading > files off the disk. > > Signed-off-by: Josef Bacik <josef@xxxxxxxxxxxxxx> > --- > > I'm not married to the rescue=onlyfs name, if we can think of something better > I'm good. > > Also rescue=skipbg is currently only sitting in misc-next, which is why I'm > killing it with this patch, we haven't sent it upstream so we're good to change > it now before it lands. Right now we don't seem to have a consensus what rescue= should or should not do and given that the patch is not in any released branch I can keep it in for-next topic branch. We'll have something to test but unless the final semantics is agreed on, I don't want to keep the patch in misc-next to avoid dealing with the fallouts. To be specific: - patch "btrfs: introduce "rescue=" mount option" only wraps existing options so that one is probably ok to stay in misc-next - rescue=skipbg would go to topic branch
