Message-ID: <5d5c170949a5c4e2e4b8ef8949e5cdc5110eeabf.camel@hammerspace.com>
Date:   Fri, 25 Mar 2022 16:42:27 +0000
From:   Trond Myklebust <trondmy@...merspace.com>
To:     "david@...morbit.com" <david@...morbit.com>,
        "miklos@...redi.hu" <miklos@...redi.hu>
CC:     "raven@...maw.net" <raven@...maw.net>,
        "kzak@...hat.com" <kzak@...hat.com>,
        "dhowells@...hat.com" <dhowells@...hat.com>,
        "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
        "linux-api@...r.kernel.org" <linux-api@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-security-module@...r.kernel.org" 
        <linux-security-module@...r.kernel.org>,
        "mszeredi@...hat.com" <mszeredi@...hat.com>,
        "torvalds@...ux-foundation.org" <torvalds@...ux-foundation.org>,
        "viro@...iv.linux.org.uk" <viro@...iv.linux.org.uk>,
        "linux-man@...r.kernel.org" <linux-man@...r.kernel.org>,
        "amir73il@...il.com" <amir73il@...il.com>,
        "christian@...uner.io" <christian@...uner.io>,
        "James.Bottomley@...senpartnership.com" 
        <James.Bottomley@...senpartnership.com>
Subject: Re: [RFC PATCH] getvalues(2) prototype

On Fri, 2022-03-25 at 07:31 +1100, Dave Chinner wrote:
> On Thu, Mar 24, 2022 at 09:57:26AM +0100, Miklos Szeredi wrote:
> > On Wed, 23 Mar 2022 at 23:58, Dave Chinner <david@...morbit.com>
> > wrote:
> > > 
> > > On Tue, Mar 22, 2022 at 08:27:12PM +0100, Miklos Szeredi wrote:
> > 
> > > > - Interfaces for getting various attributes and statistics are
> > > > fragmented.
> > > >   For files we have basic stat, statx, extended attributes,
> > > > file attributes
> > > >   (for which there are two overlapping ioctl interfaces).  For
> > > > mounts and
> > > >   superblocks we have stat*fs as well as
> > > > /proc/$PID/{mountinfo,mountstats}.
> > > >   The latter also has the problem on not allowing queries on a
> > > > specific
> > > >   mount.
> > > 
> > > https://xkcd.com/927/
> > 
> > Haha!
> > 
> > > I've said in the past when discussing things like statx() that
> > > maybe
> > > everything should be addressable via the xattr namespace and
> > > set/queried via xattr names regardless of how the filesystem
> > > stores
> > > the data. The VFS/filesystem simply translates the name to the
> > > storage location of the information. It might be held in xattrs,
> > > but
> > > it could just be a flag bit in an inode field.
> > 
> > Right, that would definitely make sense for inode attributes.
> > 
> > What about other objects' attributes, statistics?   Remember this
> > started out as a way to replace /proc/self/mountinfo with something
> > that can query individual mount.
> 
> For individual mount info, why do we even need to query something in
> /proc? I mean, every open file in the mount has access to the mount
> and the underlying superblock, so why not just make the query
> namespace accessable from any open fd on that mount?
> 
> e.g. /proc/self/mountinfo tells you where the mounts are, then you
> can just open(O_PATH) the mount point you want the info from and
> retrieve the relevant xattrs from that fd. The information itself
> does not need to be in /proc, nor only accessible from /proc, nor be
> limited to proc infrastructure, nor be constrained by proc's
> arbitrary "one value per file" presentation....
> 
> Indeed, we don't have to centralise all the information in one place
> - all we need is to have a well defined, consistent method for
> indexing that information and all the shenanigans for accessing
> common stuff can be wrapped up in a common userspace library
> (similar to how iterating the mount table is generic C library
> functionality).
> 
> > > > mnt                    - list of mount parameters
> > > > mnt:mountpoint         - the mountpoint of the mount of $ORIGIN
> > > > mntns                  - list of mount ID's reachable from the
> > > > current root
> > > > mntns:21:parentid      - parent ID of the mount with ID of 21
> > > > xattr:security.selinux - the security.selinux extended
> > > > attribute
> > > > data:foo/bar           - the data contained in file
> > > > $ORIGIN/foo/bar
> > > 
> > > How are these different from just declaring new xattr namespaces
> > > for
> > > these things. e.g. open any file and list the xattrs in the
> > > xattr:mount.mnt namespace to get the list of mount parameters for
> > > that mount.
> > 
> > Okay.
> > 
> > > Why do we need a new "xattr in everything but name" interface
> > > when
> > > we could just extend the one we've already got and formalise a
> > > new,
> > > cleaner version of xattr batch APIs that have been around for 20-
> > > odd
> > > years already?
> > 
> > Seems to make sense. But...will listxattr list everyting
> > recursively?
> > I guess that won't work, better just list traditional xattrs,
> > otherwise we'll likely get regressions,
> 
> *nod*
> 
> > and anyway the point of a
> > hierarchical namespace is to be able to list nodes on each level. 
> > We
> > can use getxattr() for this purpose, just like getvalues() does in
> > the
> > above example.
> 
> Yup, and like Casey suggests, you could implement a generic
> getvalues()-like user library on top of it so users don't even need
> to know where and how the values are located or retrieved.
> 
> The other advantage of an xattr interface is that is also provides a
> symmetrical API for -changing- values. No need for some special
> configfs or configfd thingy for setting parameters - just change the
> value of the parameter or mount option with a simple setxattr call.
> That retains the simplicity of proc and sysfs attributes in that you
> can change them just by writing a new value to the file....

The downsides are, however, that the current interface provides little
in the way of atomicity if you want to read or write to multiple
attributes at the same time. Something like a backup program might want
to be able to atomically retrieve the ctime when it is backing up the
attributes.
Also, when setting attributes, I'd like to avoid multiple syscalls when
I'm changing multiple related attributes.

IOW: Adding a batching interface that is akin to what Miklos was
proposing would be a helpful change if we want to go down this path.

-- 
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trond.myklebust@...merspace.com

Powered by blists - more mailing lists