Re: [LSF/MM/BPF TOPIC] Support to split superblocks during remount

[Al Viro <viro@zeniv.linux.org.uk>]

On Tue, Feb 17, 2026 at 10:15:58AM +0530, Shyam Prasad N wrote:
> Filesystems today use sget/sget_fc at the time of mount to share
> superblocks when possible to reuse resources. Often the reuse of
> superblocks is a function of the mount options supplied. At the time
> of umount, VFS handles the cleaning up of the superblock and only
> notifies the filesystem when the last of those references is dropped.
> 
> Some mount options could change during remount, and remount is
> associated with a mount point and not the superblock it uses. Ideally,
> during remount, the mount API needs to provide the filesystem an
> option to call sget to get a new superblock (that can also be shared)
> and do a put_super on the old superblock.
> 
> I do realize that there are challenges here about how to transparently
> failover resources (files, inodes, dentries etc) to the new
> superblock.

That's putting it way too mildly.  A _lot_ of places rely upon the following:
	* any struct inode instance belongs to the same superblock through the
entire lifetime.  ->i_sb is assign-once and can be accessed as such.
	* any struct dentry instance belongs to the same superblock through
the entire lifetime; ->d_sb is assign-once and can be accessed as such.  If it's
postive, the corresponding inode will belong to the same superblock.
	* any struct mount instance is associated with the same superblock
through the entire lifetime; ->mnt_sb is assign-once and can be accessed as such.
	* any opened file is associated with the same dentry and mount through
the entire lifetime; mount and dentry are from the same superblock.

Exclusion that would required to cope with the possibility of the above
being violated would cost far too much, and that's without going into the
amount of analysis needed to make sure that things wouldn't break.

Which filesystem do you have in mind?