Re: [LSF/MM/BPF TOPIC] Filesystem Suspend Resume

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Thu, 2025-03-20 at 09:48 -0700, Christoph Hellwig wrote:
> On Thu, Mar 20, 2025 at 11:36:17AM -0400, James Bottomley wrote:
> > Part of the thought here is that other filesystems might possibly
> > want suspend resume hooks as well, although not for the reasons
> > efivarfs does:  Hibernate is a particularly risky operation and
> > resume may not work leading to a full reboot and filesystem
> > inconsistencies. In many ways, a failed resume is exactly like a
> > system crash, for which filesystems already make specific
> > guarantees.  However, it is a crash for which they could, if they
> > had power management hooks, be forewarned and possibly make the
> > filesystem cleaner for eventual full restore. Things like
> > guaranteeing that uncommitted data would be preserved even
> > if a resume failed, which isn't something we guarantee across a
> > crash today.
> 
> We finally got hibernate to freeze file system on suspend, which is
> the right thing for the above reasons.

Agreed, so perhaps there are no other reasons a real filesystem would
like to know.

> This might not work quite as well for virtual file systems tied to an
> actualy resource like efivarsfs, so you might just register a fake
> device to get the system suspend/resume notifications for it.  Or
> whatever better way the PM and device model maintainers things that
> suites, but definitively something that isn't a file system
> interface.

Yes, we register a blocking notifier for power management via
register_pm_notifier() so no device is involved (useful because we
don't have one).  The notifier is unregistered in ->kill_sb() which is
why we get "interesting" deadlock possibilities.

Regards,

James