[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <107666.1582907766@warthog.procyon.org.uk>
Date: Fri, 28 Feb 2020 16:36:06 +0000
From: David Howells <dhowells@...hat.com>
To: Christian Brauner <christian.brauner@...ntu.com>
Cc: dhowells@...hat.com,
James Bottomley <James.Bottomley@...senPartnership.com>,
Steven Whitehouse <swhiteho@...hat.com>,
Miklos Szeredi <miklos@...redi.hu>,
Miklos Szeredi <mszeredi@...hat.com>,
viro <viro@...iv.linux.org.uk>, Ian Kent <raven@...maw.net>,
Christian Brauner <christian@...uner.io>,
Jann Horn <jannh@...gle.com>,
"Darrick J. Wong" <darrick.wong@...cle.com>,
Linux API <linux-api@...r.kernel.org>,
linux-fsdevel <linux-fsdevel@...r.kernel.org>,
lkml <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 00/17] VFS: Filesystem information and notifications [ver #17]
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.
(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).
(3) It gives people extra, indirect ways to pin mount objects and
superblocks.
For the moment, fsinfo() gives you three ways of referring to a filesystem
object:
(a) Directly by path.
(b) By path associated with an fd.
(c) By mount ID (perm checked by working back up the tree).
but will need to add:
(d) By fscontext fd (which is hard to find in sysfs). Indeed, the superblock
may not even exist yet.
David
Powered by blists - more mailing lists