Messages in this thread | | | Date | Wed, 23 Mar 2022 16:17:03 -0700 | Subject | Re: [RFC PATCH] getvalues(2) prototype | From | Casey Schaufler <> |
| |
On 3/23/2022 3:58 PM, Dave Chinner wrote: > On Tue, Mar 22, 2022 at 08:27:12PM +0100, Miklos Szeredi wrote: >> Add a new userspace API that allows getting multiple short values in a >> single syscall. >> >> This would be useful for the following reasons: >> >> - Calling open/read/close for many small files is inefficient. E.g. on my >> desktop invoking lsof(1) results in ~60k open + read + close calls under >> /proc and 90% of those are 128 bytes or less. > How does doing the open/read/close in a single syscall make this any > more efficient? All it saves is the overhead of a couple of > syscalls, it doesn't reduce any of the setup or teardown overhead > needed to read the data itself.... > >> - 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/ > >> - Some attributes are cheap to generate, some are expensive. Allowing >> userspace to select which ones it needs should allow optimizing queries. >> >> - Adding an ascii namespace should allow easy extension and self >> description. >> >> - The values can be text or binary, whichever is fits best. >> >> The interface definition is: >> >> struct name_val { >> const char *name; /* in */ >> struct iovec value_in; /* in */ >> struct iovec value_out; /* out */ >> uint32_t error; /* out */ >> uint32_t reserved; >> }; > Ahhh, XFS_IOC_ATTRMULTI_BY_HANDLE reborn. This is how xfsdump gets > and sets attributes efficiently when dumping and restoring files - > it's an interface that allows batches of xattr operations to be run > on a file in a single syscall. > > 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. > > Then we just get named xattrs in batches from an open fd. > >> int getvalues(int dfd, const char *path, struct name_val *vec, size_t num, >> unsigned int flags); >> >> @dfd and @path are used to lookup object $ORIGIN. @vec contains @num >> name/value descriptors. @flags contains lookup flags for @path. >> >> The syscall returns the number of values filled or an error. >> >> A single name/value descriptor has the following fields: >> >> @name describes the object whose value is to be returned. E.g. >> >> 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.
There is a significant and vocal set of people who dislike xattrs passionately. I often hear them whinging whenever someone proposes using them. I think that your suggestion has all the advantages of the getvalues(2) interface while also addressing its shortcomings. If we could get it past the anti-xattr crowd we might have something. You could even provide getvalues() on top of it.
> > 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? > > Cheers, > > Dave. >
| |