On Tue, May 03, 2016 at 07:55:33PM +0200, Carlos Maiolino wrote: > Hi folks, > > I spoke with Dave and to offload him a bit, I took over his patchset for enable > configurable error handlers. > > Since he did most of the design, I kept his signed-off to the patches. > > Here are core the changes I did from his last patchset to this one: > > - Removed fail_speed configuration > According with what has been discussed, there is no real need to have a > fail_speed configuration, but instead, use the "max_retries" configuration to > get for how long the filesystem should retrying, with the only special case for > "-1", which will make the filesystem to retry forever. > > - Fail at unmount is no longer a config option > Having a filesystem stuck forever during unmount due errors is not a > good thing, so just enforce it if we are trying to unmount a failed > filesystem. I think this is wrong - the option should still remain to let the filesystem retry for a long while if desired. We have lazy unmounts to deal with this situation (i.e. it won't block an unmount command) and there are cases where leaving the unmount retrying in the background is useful. If you are particularly worried about not being able to shut down a filesystem that has been unmounted lazily and hence terminate the retry forever loop, then we should be looking at ensuring the fs is still visible in /sys/fs/xfs/<dev> when it is in this state and providing a new shutdown hook through that interface.... > I reduced by now, the amount of patches into this patchset, once, our priority > here IMHO is to enable the possibility to shutdown the filesystem when we have > metadata errors, and I can work on disabling specific error configs and add > memory errors later, I hope that with a reduced amount of patches it can be > easier for people to review the core of the error handlers configuration and > speed up the inclusion of this patchset. We'll see - the issue here is that once we settle on a sysfs interface, we can't change it easily (it's part of the user facing ABI). Hence if we don't consider all the different types of errors we want to handle from the start, we may miss something that we can't easily fix in future. Hence we at least have to consider the different constraints for the different error types now to determine if the abstractions and presentation will handle everything we think we might need... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
