Re: [PATCH 00/17] VFS: Filesystem information and notifications [ver #17]

Karel Zak
2020-03-02T10:34:16Z

On Fri, Feb 28, 2020 at 05:24:23PM +0100, Miklos Szeredi wrote:
> ned-By: MIMEDefang 2.78 on 10.11.54.4
>
> On Fri, Feb 28, 2020 at 1:27 PM Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
>
> > > Superblocks and mounts could get enumerated by a unique identifier.
> > > mnt_id seems to be good for mounts, s_dev may or may not be good for
> > > superblock, but s_id (as introduced in this patchset) could be used
> > > instead.
> >
> > So what would the sysfs tree look like with this?
>
> For a start something like this:
>
> mounts/$MOUNT_ID/
> parent -> ../$PARENT_ID
> super -> ../../supers/$SUPER_ID
> root: path from mount root to fs root (could be optional as usually
> they are the same)
> mountpoint -> $MOUNTPOINT
> flags: mount flags
> propagation: mount propagation
> children/$CHILD_ID -> ../../$CHILD_ID
>
> supers/$SUPER_ID/
> type: fstype
> source: mount source (devname)
> options:

What about use-cases where I have no ID, but I have mountpoint path
(e.g. "umount /foo")? In this case I have to go to open() + fsinfo()
and then sysfs does not make sense for me, right?

Karel

--
Karel Zak <kzak@redhat.com>