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

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

[Shyam Prasad N]

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. I would still like to understand if this is an idea worth
pursuing?

-- 
Regards,
Shyam

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

[Aleksa Sarai]

[-- Attachment #1: Type: text/plain, Size: 1603 bytes --]

On 2026-02-17, Shyam Prasad N <nspmangalore@gmail.com> 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. I would still like to understand if this is an idea worth
> pursuing?

I gave a talk at LPC 2025 about making the mount API more amenable to
reporting these kinds of confusing behaviours with regards to mount
options[1].

It seems to me that doing this kind of splitting is far less preferable
than providing a more robust mechanism to tell userspace about what
exact mount flags were ignored (or were already applied). This has some
other issues (as Christian explains during the discussion segment) but
it seems like a more workable solution to me and is closer to what
userspace would want.

[1]: https://www.youtube.com/watch?v=NX5IzF6JXp0

-- 
Aleksa Sarai
https://www.cyphar.com/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 265 bytes --]

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

[Shyam Prasad N]

On Wed, Feb 18, 2026 at 8:30 AM Aleksa Sarai <cyphar@cyphar.com> wrote:
>
> On 2026-02-17, Shyam Prasad N <nspmangalore@gmail.com> 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. I would still like to understand if this is an idea worth
> > pursuing?
>
> I gave a talk at LPC 2025 about making the mount API more amenable to
> reporting these kinds of confusing behaviours with regards to mount
> options[1].
>
> It seems to me that doing this kind of splitting is far less preferable
> than providing a more robust mechanism to tell userspace about what
> exact mount flags were ignored (or were already applied). This has some
> other issues (as Christian explains during the discussion segment) but
> it seems like a more workable solution to me and is closer to what
> userspace would want.
>
> [1]: https://www.youtube.com/watch?v=NX5IzF6JXp0
>
> --
> Aleksa Sarai
> https://www.cyphar.com/

Thanks for sharing this. Will go over the details shared to understand
more about what you said.

-- 
Regards,
Shyam

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

[Al Viro]

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?

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

[Christian Brauner]

On Tue, Feb 24, 2026 at 05:17:29AM +0000, Al Viro wrote:
> 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.

I'm very very skeptical about all of this and would really do everything
we can do avoid this...

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

[Shyam Prasad N]

On Tue, Feb 24, 2026 at 10:44 AM Al Viro <viro@zeniv.linux.org.uk> wrote:
>
> 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?

The following code use sget* with test functions today:
afs, btrfs, ceph, fuse, gfs2, nfs, ubifs, smb/client
... which means that they can share superblocks.

If those test functions use mount options to decide whether to share a
superblock (at least nfs and smb clients do this), those mount options
can change during remount.
At this point, the filesystems do not even have visibility into other
mounts that share the superblock. Hence they cannot even fail such
remounts.
Side effect of such remounts is that changes to mount options will
apply to all mounts that share the superblock, whether the user
intended to do that or not.

-- 
Regards,
Shyam