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.
Moreover, during hibernation devices are suspended for two times (and
resumed in between, of course) whereas filesystems only need to be
"suspended" once.
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.
