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.��.n��������+%������w��{.n�����{����� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
