From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: David Howells <dhowells@redhat.com>,
Christian Brauner <christian.brauner@ubuntu.com>,
James Bottomley <James.Bottomley@hansenpartnership.com>,
Steven Whitehouse <swhiteho@redhat.com>,
Miklos Szeredi <mszeredi@redhat.com>,
viro <viro@zeniv.linux.org.uk>, Ian Kent <raven@themaw.net>,
Christian Brauner <christian@brauner.io>,
Jann Horn <jannh@google.com>,
"Darrick J. Wong" <darrick.wong@oracle.com>,
Linux API <linux-api@vger.kernel.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
lkml <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 00/17] VFS: Filesystem information and notifications [ver #17]
Date: Mon, 2 Mar 2020 10:38:50 +0100 [thread overview]
Message-ID: <20200302093850.GA1998325@kroah.com> (raw)
In-Reply-To: <CAJfpegu0qHBZ7iK=R4ajmmHC4g=Yz56otpKMy5w-y0UxJ1zO+Q@mail.gmail.com>
On Mon, Mar 02, 2020 at 10:09:51AM +0100, Miklos Szeredi wrote:
> On Fri, Feb 28, 2020 at 5:36 PM David Howells <dhowells@redhat.com> wrote:
> >
> > 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...
>
> >
> > (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
next prev parent reply other threads:[~2020-03-02 9:38 UTC|newest]
Thread overview: 117+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-21 18:01 [PATCH 00/17] VFS: Filesystem information and notifications [ver #17] David Howells
2020-02-21 18:01 ` [PATCH 01/17] watch_queue: Add security hooks to rule on setting mount and sb watches " David Howells
2020-02-21 18:02 ` [PATCH 02/17] watch_queue: Implement mount topology and attribute change notifications " David Howells
2020-02-21 18:02 ` [PATCH 03/17] watch_queue: sample: Display mount tree " David Howells
2020-02-21 18:02 ` [PATCH 04/17] watch_queue: Introduce a non-repeating system-unique superblock ID " David Howells
2020-02-21 18:02 ` [PATCH 05/17] watch_queue: Add superblock notifications " David Howells
2020-02-21 18:02 ` [PATCH 06/17] watch_queue: sample: Display " David Howells
2020-02-21 18:02 ` [PATCH 07/17] fsinfo: Add fsinfo() syscall to query filesystem information " David Howells
2020-02-26 2:29 ` Aleksa Sarai
2020-02-28 14:44 ` David Howells
2020-02-21 18:02 ` [PATCH 08/17] fsinfo: Provide a bitmap of supported features " David Howells
2020-02-21 18:03 ` [PATCH 09/17] fsinfo: Allow fsinfo() to look up a mount object by ID " David Howells
2020-02-21 18:03 ` [PATCH 10/17] fsinfo: Allow mount information to be queried " David Howells
2020-03-04 14:58 ` Miklos Szeredi
2020-03-04 16:10 ` Miklos Szeredi
2020-02-21 18:03 ` [PATCH 11/17] fsinfo: sample: Mount listing program " David Howells
2020-02-21 18:03 ` [PATCH 12/17] fsinfo: Allow the mount topology propogation flags to be retrieved " David Howells
2020-02-21 18:03 ` [PATCH 13/17] fsinfo: Query superblock unique ID and notification counter " David Howells
2020-02-21 18:03 ` [PATCH 14/17] fsinfo: Add API documentation " David Howells
2020-02-21 18:03 ` [PATCH 15/17] fsinfo: Add support for AFS " David Howells
2020-02-21 18:03 ` [PATCH 16/17] fsinfo: Add example support for Ext4 " David Howells
2020-02-21 18:04 ` [PATCH 17/17] fsinfo: Add example support for NFS " David Howells
2020-02-21 20:21 ` [PATCH 00/17] VFS: Filesystem information and notifications " James Bottomley
2020-02-24 10:24 ` Miklos Szeredi
2020-02-24 14:55 ` James Bottomley
2020-02-24 15:28 ` Miklos Szeredi
2020-02-25 12:13 ` Steven Whitehouse
2020-02-25 15:28 ` James Bottomley
2020-02-25 15:47 ` Steven Whitehouse
2020-02-26 9:11 ` Miklos Szeredi
2020-02-26 10:51 ` Steven Whitehouse
2020-02-27 5:06 ` Ian Kent
2020-02-27 9:36 ` Miklos Szeredi
2020-02-27 11:34 ` Ian Kent
2020-02-27 13:45 ` Miklos Szeredi
2020-02-27 15:14 ` Karel Zak
2020-02-28 0:43 ` Ian Kent
2020-02-28 8:35 ` Miklos Szeredi
2020-02-28 12:27 ` Greg Kroah-Hartman
2020-02-28 16:24 ` Miklos Szeredi
2020-02-28 17:15 ` Al Viro
2020-03-02 8:43 ` Miklos Szeredi
2020-03-02 10:34 ` Karel Zak
2020-02-28 16:42 ` David Howells
2020-02-28 15:08 ` James Bottomley
2020-02-28 15:40 ` Miklos Szeredi
2020-02-28 0:12 ` Ian Kent
2020-02-28 15:52 ` Christian Brauner
2020-02-28 16:36 ` David Howells
2020-03-02 9:09 ` Miklos Szeredi
2020-03-02 9:38 ` Greg Kroah-Hartman [this message]
2020-03-03 5:27 ` Ian Kent
2020-03-03 7:46 ` Miklos Szeredi
2020-03-06 16:25 ` Miklos Szeredi
2020-03-06 19:43 ` Al Viro
2020-03-06 19:54 ` Miklos Szeredi
2020-03-06 19:58 ` Al Viro
2020-03-06 20:05 ` Al Viro
2020-03-06 20:11 ` Miklos Szeredi
2020-03-06 20:37 ` Al Viro
2020-03-06 20:38 ` Al Viro
2020-03-06 20:45 ` Al Viro
2020-03-06 20:49 ` Al Viro
2020-03-06 20:51 ` Miklos Szeredi
2020-03-06 21:28 ` Al Viro
2020-03-06 20:56 ` Al Viro
2020-03-06 20:51 ` Miklos Szeredi
2020-03-07 9:48 ` Greg Kroah-Hartman
2020-03-07 20:48 ` Miklos Szeredi
2020-03-03 9:12 ` David Howells
2020-03-03 9:26 ` Miklos Szeredi
2020-03-03 9:48 ` Miklos Szeredi
2020-03-03 10:21 ` Steven Whitehouse
2020-03-03 10:32 ` Miklos Szeredi
2020-03-03 11:09 ` Ian Kent
2020-03-03 10:00 ` Christian Brauner
2020-03-03 10:13 ` Miklos Szeredi
2020-03-03 10:25 ` Christian Brauner
2020-03-03 11:33 ` Miklos Szeredi
2020-03-03 11:56 ` Christian Brauner
2020-03-03 11:38 ` Karel Zak
2020-03-03 13:03 ` Greg Kroah-Hartman
2020-03-03 13:14 ` Greg Kroah-Hartman
2020-03-03 13:34 ` Miklos Szeredi
2020-03-03 13:43 ` Greg Kroah-Hartman
2020-03-03 14:10 ` Greg Kroah-Hartman
2020-03-03 14:13 ` Jann Horn
2020-03-03 14:24 ` Greg Kroah-Hartman
2020-03-03 15:44 ` Jens Axboe
2020-03-03 16:37 ` Greg Kroah-Hartman
2020-03-03 16:51 ` Jeff Layton
2020-03-03 16:55 ` Jens Axboe
2020-03-03 19:02 ` Jeff Layton
2020-03-03 19:07 ` Jens Axboe
2020-03-03 19:23 ` Jens Axboe
2020-03-03 19:43 ` Jeff Layton
2020-03-03 20:33 ` Jens Axboe
2020-03-03 21:03 ` Jeff Layton
2020-03-03 21:20 ` Jens Axboe
2020-03-03 14:10 ` Miklos Szeredi
2020-03-03 14:29 ` Greg Kroah-Hartman
2020-03-03 14:40 ` Jann Horn
2020-03-03 16:51 ` Greg Kroah-Hartman
2020-03-03 16:57 ` Jann Horn
2020-03-03 20:15 ` Greg Kroah-Hartman
2020-03-03 14:40 ` David Howells
2020-03-04 4:20 ` Ian Kent
2020-03-03 14:19 ` David Howells
2020-03-03 16:59 ` Greg Kroah-Hartman
2020-03-03 14:23 ` Christian Brauner
2020-03-03 15:23 ` Greg Kroah-Hartman
2020-03-03 15:53 ` David Howells
2020-03-04 2:01 ` Ian Kent
2020-03-04 15:22 ` Karel Zak
2020-03-04 16:49 ` Greg Kroah-Hartman
2020-03-04 17:55 ` Karel Zak
2020-03-03 14:09 ` David Howells
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200302093850.GA1998325@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=James.Bottomley@hansenpartnership.com \
--cc=christian.brauner@ubuntu.com \
--cc=christian@brauner.io \
--cc=darrick.wong@oracle.com \
--cc=dhowells@redhat.com \
--cc=jannh@google.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=mszeredi@redhat.com \
--cc=raven@themaw.net \
--cc=swhiteho@redhat.com \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.