Thread (48 messages) 48 messages, 10 authors, 2023-04-19

Re: [RFC PATCH] getting misc stats/attributes via xattr API

From: Dave Chinner <david@fromorbit.com>
Date: 2022-05-03 22:43:15
Also in: linux-fsdevel, linux-man, linux-security-module, lkml

On Tue, May 03, 2022 at 02:23:23PM +0200, Miklos Szeredi wrote:
This is a simplification of the getvalues(2) prototype and moving it to the
getxattr(2) interface, as suggested by Dave.

The patch itself just adds the possibility to retrieve a single line of
/proc/$$/mountinfo (which was the basic requirement from which the fsinfo
patchset grew out of).

But this should be able to serve Amir's per-sb iostats, as well as a host of
other cases where some statistic needs to be retrieved from some object.  Note:
a filesystem object often represents other kinds of objects (such as processes
in /proc) so this is not limited to fs attributes.

This also opens up the interface to setting attributes via setxattr(2).

After some pondering I made the namespace so:

: - root
bar - an attribute
foo: - a folder (can contain attributes and/or folders)

The contents of a folder is represented by a null separated list of names.

Examples:

$ getfattr -etext -n ":" .
# file: .
:="mnt:\000mntns:"

$ getfattr -etext -n ":mnt:" .
# file: .
:mnt:="info"

$ getfattr -etext -n ":mnt:info" .
# file: .
:mnt:info="21 1 254:0 / / rw,relatime - ext4 /dev/root rw\012"

$ getfattr -etext -n ":mntns:" .
# file: .
:mntns:="21:\00022:\00024:\00025:\00023:\00026:\00027:\00028:\00029:\00030:\00031:"

$ getfattr -etext -n ":mntns:28:" .
# file: .
:mntns:28:="info"

Comments?
I like. :)
Thanks,
Miklos

---
 fs/Makefile            |    2 
 fs/mount.h             |    8 +
 fs/namespace.c         |   15 ++-
 fs/pnode.h             |    2 
 fs/proc_namespace.c    |   15 ++-
 fs/values.c            |  242 +++++++++++++++++++++++++++++++++++++++++++++++++
 fs/xattr.c             |   16 ++-
 include/linux/values.h |   11 ++
"values" is a very generic name - probably should end up being
something more descriptive of the functionality is provides,
especially if the header file is going to be dumped in
include/linux/. I don't really have a good suggestion at the moment,
though. 

....
+
+enum {
+	VAL_MNT_INFO,
+};
+
+static struct val_desc val_mnt_group[] = {
+	{ VD_NAME("info"),		.idx = VAL_MNT_INFO		},
+	{ }
+};
....
+
+
+static struct val_desc val_toplevel_group[] = {
+	{ VD_NAME("mnt:"),	.get = val_mnt_get,	},
+	{ VD_NAME("mntns:"),	.get = val_mntns_get,	},
+	{ },
+};
I know this is an early POC, my main question is how do you
envisiage this table driven structure being extended down from just
the mount into the filesystem so we can expose filesystem specific
information that isn't covered by generic interfaces like statx?

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help