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:

quoted

On Wed, 23 Mar 2022 at 23:58, Dave Chinner [off-list ref]
wrote:

quoted

On Tue, Mar 22, 2022 at 08:27:12PM +0100, Miklos Szeredi wrote:

quoted

quoted

- 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!

quoted

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).

quoted

quoted

quoted

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.

quoted

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*

quoted

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@hammerspace.com