On Mon, Feb 05, 2018 at 09:28:37AM +0100, Rafael J. Wysocki wrote:
> On Sun, Feb 4, 2018 at 11:41 PM, Bart Van Assche <Bart.VanAssche@xxxxxxx> wrote:
> > On Wed, 2018-01-31 at 11:10 -0800, Darrick J. Wong wrote:
> >> For a brief moment I pondered whether it would make sense to make
> >> filesystems part of the device model so that the suspend code could work
> >> out fs <-> bdev dependencies and know in which order to freeze
> >> filesystems and quiesce devices, but every time I go digging into how
> >> all those macros work I get confused and my eyes glaze over, so I don't
> >> know if this is at all a good idea or just confused ramblings.
> >
> > If we have to go this way: shouldn't we introduce a new abstraction
> > ("storage stack element" or similar) rather than making filesystems part of
> > the device model?
>
> That would be my approach.
>
> Trying to "suspend" filesystems at the same time as I/O devices (and
> all of that asynchronously) may be problematic for ordering reasons
> and similar.
Oh look, another ordering issue. And this is why I was not a fan of the
device link API even though that is what we got merged. Moving on...
> Moreover, during hibernation devices are suspended for two times (and
> resumed in between, of course) whereas filesystems only need to be
> "suspended" once.
>From your point of view yes, but actually internally the VFS layer or
filesystems themselves may end up re-using this mechanism later for
other things like -- snapshotting. And if some folks have it the way
they want it, we may need a dependency map between filesystems anyway
for filesystem specific reasons.
> With that in mind, I would add a mechanism allowing filesystems (and
> possibly other components of the storage stack) to register a set of
> callbacks for suspend and resume and then invoking those callbacks in
> a specific order.
That's what I had done in my series, the issue here is order. Order in my
series is simple but should work for starters, later however I suspect we'll
need something more robust to help.
Luis
