From: Eric Biggers <ebiggers@kernel.org>
To: David Howells <dhowells@redhat.com>
Cc: viro@zeniv.linux.org.uk, raven@themaw.net, mszeredi@redhat.com,
christian@brauner.io, linux-api@vger.kernel.org,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 00/11] VFS: Introduce filesystem information query syscall [ver #15]
Date: Tue, 2 Jul 2019 11:15:40 -0700 [thread overview]
Message-ID: <20190702181539.GA110306@gmail.com> (raw)
In-Reply-To: <156173661696.14042.17822154531324224780.stgit@warthog.procyon.org.uk>
On Fri, Jun 28, 2019 at 04:43:37PM +0100, David Howells wrote:
>
> Here are a set of patches that adds a syscall, fsinfo(), that allows
> attributes of a filesystem/superblock to be queried. Attribute values are
> of four basic types:
>
> (1) Version dependent-length structure (size defined by type).
>
> (2) Variable-length string (up to 4096, no NUL).
>
> (3) Array of fixed-length structures (up to INT_MAX size).
>
> (4) Opaque blob (up to INT_MAX size).
>
> Attributes can have multiple values either as a sequence of values or a
> sequence-of-sequences of values and all the values of a particular
> attribute must be of the same type.
>
> Note that the values of an attribute *are* allowed to vary between dentries
> within a single superblock, depending on the specific dentry that you're
> looking at.
>
> I've tried to make the interface as light as possible, so integer/enum
> attribute selector rather than string and the core does all the allocation
> and extensibility support work rather than leaving that to the filesystems.
> That means that for the first two attribute types, sb->s_op->fsinfo() may
> assume that the provided buffer is always present and always big enough.
>
> Further, this removes the possibility of the filesystem gaining access to the
> userspace buffer.
>
>
> fsinfo() allows a variety of information to be retrieved about a filesystem
> and the mount topology:
>
> (1) General superblock attributes:
>
> - The amount of space/free space in a filesystem (as statfs()).
> - Filesystem identifiers (UUID, volume label, device numbers, ...)
> - The limits on a filesystem's capabilities
> - Information on supported statx fields and attributes and IOC flags.
> - A variety single-bit flags indicating supported capabilities.
> - Timestamp resolution and range.
> - Sources (as per mount(2), but fsconfig() allows multiple sources).
> - In-filesystem filename format information.
> - Filesystem parameters ("mount -o xxx"-type things).
> - LSM parameters (again "mount -o xxx"-type things).
>
> (2) Filesystem-specific superblock attributes:
>
> - Server names and addresses.
> - Cell name.
>
> (3) Filesystem configuration metadata attributes:
>
> - Filesystem parameter type descriptions.
> - Name -> parameter mappings.
> - Simple enumeration name -> value mappings.
>
> (4) Information about what the fsinfo() syscall itself supports, including
> the number of attibutes supported and the number of capability bits
> supported.
>
> (5) Future patches will include information about the mount topology.
>
> The system is extensible:
>
> (1) New attributes can be added. There is no requirement that a
> filesystem implement every attribute. Note that the core VFS keeps a
> table of types and sizes so it can handle future extensibility rather
> than delegating this to the filesystems.
>
> (2) Version length-dependent structure attributes can be made larger and
> have additional information tacked on the end, provided it keeps the
> layout of the existing fields. If an older process asks for a shorter
> structure, it will only be given the bits it asks for. If a newer
> process asks for a longer structure on an older kernel, the extra
> space will be set to 0. In all cases, the size of the data actually
> available is returned.
>
> In essence, the size of a structure is that structure's version: a
> smaller size is an earlier version and a later version includes
> everything that the earlier version did.
>
> (3) New single-bit capability flags can be added. This is a structure-typed
> attribute and, as such, (2) applies. Any bits you wanted but the kernel
> doesn't support are automatically set to 0.
>
> If a filesystem-specific attribute is added, it should just take up the next
> number in the enumeration. Currently, I do not intend that the number space
> should be subdivided between interested parties.
>
>
> fsinfo() may be called like the following, for example:
>
> struct fsinfo_params params = {
> .at_flags = AT_SYMLINK_NOFOLLOW,
> .request = FSINFO_ATTR_SERVER_ADDRESS;
> .Nth = 2;
> .Mth = 1;
> };
> struct fsinfo_server_address address;
>
> len = fsinfo(AT_FDCWD, "/afs/grand.central.org/doc", ¶ms,
> &address, sizeof(address));
>
> The above example would query a network filesystem, such as AFS or NFS, and
> ask what the 2nd address (Mth) of the 3rd server (Nth) that the superblock is
> using is. Whereas:
>
> struct fsinfo_params params = {
> .at_flags = AT_SYMLINK_NOFOLLOW,
> .request = FSINFO_ATTR_AFS_CELL_NAME;
> };
> char cell_name[256];
>
> len = fsinfo(AT_FDCWD, "/afs/grand.central.org/doc", ¶ms,
> &cell_name, sizeof(cell_name));
>
> would retrieve the name of an AFS cell as a string.
>
> fsinfo() can also be used to query a context from fsopen() or fspick():
>
> fd = fsopen("ext4", 0);
> struct fsinfo_params params = {
> .request = FSINFO_ATTR_PARAM_DESCRIPTION;
> };
> struct fsinfo_param_description desc;
> fsinfo(fd, NULL, ¶ms, &desc, sizeof(desc));
>
> even if that context doesn't currently have a superblock attached (though if
> there's no superblock attached, only filesystem-specific things like parameter
> descriptions can be accessed).
>
> The patches can be found here also:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git
>
> on branch:
>
> fsinfo-core
>
>
Where are the tests and man page for this system call? "Tests" meaning actual
automated tests in a commonly used test suite (e.g. LTP, kselftests, or
xfstests), not just a sample program.
- Eric
next prev parent reply other threads:[~2019-07-02 18:15 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-28 15:43 [PATCH 00/11] VFS: Introduce filesystem information query syscall [ver #15] David Howells
2019-06-28 15:43 ` [PATCH 01/11] vfs: syscall: Add fsinfo() to query filesystem information " David Howells
2019-07-01 10:40 ` Christian Brauner
2019-07-01 13:13 ` David Howells
2019-07-02 12:58 ` Christian Brauner
2019-07-02 13:02 ` Christian Brauner
2019-06-28 15:43 ` [PATCH 02/11] fsinfo: Add syscalls to other arches " David Howells
2019-06-28 15:44 ` [PATCH 03/11] vfs: Allow fsinfo() to query what's in an fs_context " David Howells
2019-06-28 15:44 ` [PATCH 04/11] vfs: Allow fsinfo() to be used to query an fs parameter description " David Howells
2019-06-28 15:44 ` [PATCH 05/11] vfs: Implement parameter value retrieval with fsinfo() " David Howells
2019-06-28 15:44 ` [PATCH 06/11] fsinfo: Implement retrieval of LSM parameters " David Howells
2019-06-28 15:45 ` [PATCH 07/11] afs: Support " David Howells
2019-06-28 15:45 ` [PATCH 08/11] fsinfo: Add API documentation " David Howells
2019-06-28 15:45 ` [PATCH 09/11] hugetlbfs: Add support for fsinfo() " David Howells
2019-06-28 15:45 ` [PATCH 10/11] kernfs, cgroup: Add fsinfo support " David Howells
2019-06-28 15:45 ` [PATCH 11/11] fsinfo: proc - add sb operation fsinfo() " David Howells
2019-07-02 18:15 ` Eric Biggers [this message]
2019-07-02 19:10 ` fsinfo(2) manpage David Howells
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190702181539.GA110306@gmail.com \
--to=ebiggers@kernel.org \
--cc=christian@brauner.io \
--cc=dhowells@redhat.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mszeredi@redhat.com \
--cc=raven@themaw.net \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).