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
