lkml.org 
[lkml]   [2020]   [Mar]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 00/17] VFS: Filesystem information and notifications [ver #17]
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>
http://karelzak.blogspot.com

\
 
 \ /
  Last update: 2020-03-02 11:34    [W:0.134 / U:15.408 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site