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

On Mon, Mar 02, 2020 at 10:09:51AM +0100, Miklos Szeredi wrote:

On Fri, Feb 28, 2020 at 5:36 PM David Howells [off-list ref] wrote:

quoted

sysfs also has some other disadvantages for this:

 (1) There's a potential chicken-and-egg problem in that you have to create a
     bunch of files and dirs in sysfs for every created mount and superblock
     (possibly excluding special ones like the socket mount) - but this
     includes sysfs itself.  This might work - provided you create sysfs
     first.

Sysfs architecture looks something like this (I hope Greg will correct
me if I'm wrong):

device driver -> kobj tree <- sysfs tree

The kobj tree is created by the device driver, and the dentry tree is
created on demand from the kobj tree.   Lifetime of kobjs is bound to
both the sysfs objects and the device but not the other way round.
I.e. device can go away while the sysfs object is still being
referenced, and sysfs can be freely mounted and unmounted
independently of device initialization.

So there's no ordering requirement between sysfs mounts and other
mounts.   I might be wrong on the details, since mounts are created
very early in the boot process...

quoted

 (2) sysfs is memory intensive.  The directory structure has to be backed by
     dentries and inodes that linger as long as the referenced object does
     (procfs is more efficient in this regard for files that aren't being
     accessed)

See above: I don't think dentries and inodes are pinned, only kobjs
and their associated cruft.  Which may be too heavy, depending on the
details of the kobj tree.

That is correct, they should not be pinned, that is what kernfs handles
and why we can handle 30k virtual block devices on a 31bit s390 instance
:)

So you shouldn't have to worry about memory for sysfs.

There are loads of other reasons probably not to use sysfs for this
instead :)

thanks,

greg k-h