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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Mar 20, 2025 at 11:36:17AM -0400, James Bottomley wrote:
> [Note: this got scheduled because I suggested it as a topic on the
> application form.  I'm still not convinced it's that relevant and it
> could become a lightning talk instead if there's not much interest]
> 
> This came up as a problem because efivarfs needs a hibernate hook.  The
> specific efivarfs problem is that when the kernel is running, it owns
> the EFI runtime interface, so nothing can update variables without
> going through the kernel and so the cache of efivarfs (held in the
> variable dentries) reflects exactly the state of the underlying
> variables.  However, when the system is hibernated, other OSs could
> boot and alter EFI variables, so the exact cache correspondence
> guarantee is broken and efivarfs needs to resync the variable store on
> resume from hibernate.
> 
> 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.
> 
> The other reason for discussing this is that adding power management
> hooks directly to efivarfs resulted in a lot of deadlock potential
> (discussion of which is already on linux-fsdevel), which could
> potentially be lessened by making it part of the VFS API.  If other
> filesystems think they might use it in future, we should discuss how
> this could work.

there's a hook in s_ops, although today it's only called from blk_holder
ops - presumably you'd just want to add a superblock flag to say "I need
freeze/suspend hooks to be called directly"?




[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux