[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200401090445.6t73dt7gz36bv4rh@ws.net.home>
Date: Wed, 1 Apr 2020 11:04:45 +0200
From: Karel Zak <kzak@...hat.com>
To: David Howells <dhowells@...hat.com>
Cc: Christian Brauner <christian.brauner@...ntu.com>,
torvalds@...ux-foundation.org, viro@...iv.linux.org.uk,
dray@...hat.com, mszeredi@...hat.com, swhiteho@...hat.com,
jlayton@...hat.com, raven@...maw.net, andres@...razel.de,
keyrings@...r.kernel.org, linux-fsdevel@...r.kernel.org,
linux-kernel@...r.kernel.org, lennart@...ttering.net,
cyphar@...har.com
Subject: Re: Upcoming: Notifications, FS notifications and fsinfo()
On Tue, Mar 31, 2020 at 10:52:52PM +0100, David Howells wrote:
> Christian Brauner <christian.brauner@...ntu.com> wrote:
>
> > querying all properties of a mount atomically all-at-once,
>
> I don't actually offer that, per se.
>
> Having an atomic all-at-once query for a single mount is actually quite a
> burden on the system. There's potentially a lot of state involved, much of
> which you don't necessarily need.
If all means "all possible attributes" than it is unnecessary, for
example ext4 timestamps or volume uuid/label are rarely necessary.
We usually need together (as consistent set):
source
mountpoint
FS type
FS root (FSINFO_ATTR_MOUNT_PATH)
FS options (FSINFO_ATTR_CONFIGURATION)
VFS attributes
VFS propagation flags
mount ID
parent ID
devno (or maj:min)
Karel
--
Karel Zak <kzak@...hat.com>
http://karelzak.blogspot.com
Powered by blists - more mailing lists