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

On Fri, Feb 28, 2020 at 6:15 PM Al Viro [off-list ref] wrote:

On Fri, Feb 28, 2020 at 05:24:23PM +0100, Miklos Szeredi wrote:

quoted

On Fri, Feb 28, 2020 at 1:27 PM Greg Kroah-Hartman
[off-list ref] wrote:

quoted

quoted

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: csv of mount options

Oh, wonderful.  So let me see if I got it right - any namespace operation
can create/destroy/move around an arbitrary amount of sysfs objects.

Parent/children symlinks may be excessive...

Better yet, we suddenly have to express the lifetime rules for struct mount
and struct superblock in terms of struct device garbage.

How so?   struct mount and struct superblock would hold a ref on
struct device, not the other way round.

In any case, I'm not insistent on the use of sysfs device classes for
this; struct device (488B) does seem too heavy for struct mount
(328B).

What I'm pretty sure about is that a read(2) based interface would be
way more useful than the syscall multiplexer that the current proposal
is.

Thanks,
Miklos