On Thu, 2017-11-30 at 20:42 +0100, Luis R. Rodriguez wrote: > On Thu, Nov 30, 2017 at 05:01:13PM +0000, Bart Van Assche wrote: > > The md resync > > thread must be stopped before a system is frozen. Today the md driver uses > > the kthread freezing mechanism for that purpose. Do you have a plan for > > handling the more complicated scenarios, e.g. a filesystem that exists on top > > of an md device where the md device uses one or more files as backing store > > and with the loop driver between the md device and the files? > > Nope not yet. It seems you have given this some thought though so you're > help here is greatly appreciated. In fact the way we should see the long > term 'kill kthread freezing' effort should be a collaborative one. I've > never touched md, so folks more familiar with md should give this some > thought. > > Can for instance md register_pm_notifier() and register_syscore_ops() > and do handy work to pause some work to replace kthread freezing? > Note that I believe a pm notifier is needed in case syscore_suspend() > is not called, say on a suspend fail. Sorry but I don't think that a solution can be based on a notifier mechanism. Freezing has to happen in the order in which drivers and filesystems have been stacked (filesystem > md device > filesystem for the above example). Since the order in which notifiers are called is related to the order in which notifiers have been registered I don't think that a solution for the example I described can be based on notifiers. What I think we need is a mechanism for traversing the storage stack that includes block drivers and an equivalent of freeze_fs() for block drivers. Freezing should occur by calling the freeze_fs() methods for each storage layer starting at the top of the storage stack and proceeding towards the bottom. Bart.
