lkml.org 
[lkml]   [2019]   [Jun]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 00/25] VFS: Introduce filesystem information query syscall [ver #14]
    On Wed, Jun 26, 2019 at 12:05:25PM +0200, Christian Brauner wrote:
    > On Mon, Jun 24, 2019 at 03:08:45PM +0100, David Howells wrote:
    > >
    > > Hi Al,
    > >
    > > 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 PAGE_SIZE).
    > >
    > > (3) Array of fixed-length structures (up to INT_MAX size).
    > >
    > > (4) Opaque blob (up to INT_MAX size).
    > >
    > > Attributes can have multiple values in up to two dimensions and all the
    > > values of a particular attribute must have the same type.
    > >
    > > Note that the attribute values *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) Mount topology:
    > >
    > > - General information about a mount object.
    > > - Mount device name(s).
    > > - Children of a mount object and their relative paths.
    > >
    > > (5) Information about what the fsinfo() syscall itself supports, including
    > > the number of attibutes supported and the number of capability bits
    > > supported.
    >
    > Phew, this patchset is a lot. It's good of course but can we please cut
    > some of the more advanced features such as querying by mount id,
    > submounts etc. pp. for now?
    > I feel this would help with review and since your interface is
    > extensible it's really not a big deal if we defer fancy features to
    > later cycles after people had more time to review and the interface has
    > seen some exposure.
    >
    > The mount api changes over the last months have honestly been so huge
    > that any chance to make the changes smaller and easier to digest we
    > should take. (I'm really not complaining. Good that the work is done and
    > it's entirely ok that it's a lot of code.)
    >
    > It would also be great if after you have dropped some stuff from this
    > patchset and gotten an Ack we could stuff it into linux-next for some
    > time because it hasn't been so far...

    And I also very much recommend to remove any potential cross-dependency
    between the fsinfo() and the notification patchset.
    Ideally, I'd like to see fsinfo() to be completely independent to not
    block it on something way more controversial.
    Furthermore, I can't possibly keep the context of another huge patchset
    not yet merged in the back of my mind while reviewing this patchset. :)

    Christian

    \
     
     \ /
      Last update: 2019-06-26 15:19    [W:7.115 / U:0.012 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site