Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1274142 > unrolled thread

[RFC][PATCH 00/12] Enhanced file stat system call

Started byDavid Howells <dhowells@redhat.com>
First post2015-11-20 16:00 +0100
Last post2015-11-24 21:30 +0100
Articles 11 on this page of 31 — 11 participants

Back to article view | Back to linux.kernel

Contents

  [RFC][PATCH 00/12] Enhanced file stat system call David Howells <dhowells@redhat.com> - 2015-11-20 16:00 +0100
    [PATCH 04/12] statx: AFS: Return enhanced file attributes David Howells <dhowells@redhat.com> - 2015-11-20 16:00 +0100
    [PATCH 11/12] fsinfo: NFS: Return information through the  filesystem info syscall David Howells <dhowells@redhat.com> - 2015-11-20 16:00 +0100
    [PATCH 07/12] statx: CIFS: Return enhanced attributes David Howells <dhowells@redhat.com> - 2015-11-20 16:00 +0100
      Re: [PATCH 07/12] statx: CIFS: Return enhanced attributes Steve French <smfrench@gmail.com> - 2015-11-24 18:40 +0100
    [PATCH 01/12] Ext4: Fix extended timestamp encoding and decoding David Howells <dhowells@redhat.com> - 2015-11-20 16:00 +0100
      Re: [PATCH 01/12] Ext4: Fix extended timestamp encoding and decoding Andreas Dilger <adilger@dilger.ca> - 2015-11-24 18:40 +0100
      Re: [PATCH 01/12] Ext4: Fix extended timestamp encoding and decoding Theodore Ts'o <tytso@mit.edu> - 2015-11-24 20:40 +0100
        Re: [PATCH 01/12] Ext4: Fix extended timestamp encoding and decoding Arnd Bergmann <arnd@arndb.de> - 2015-11-24 21:20 +0100
          Re: [PATCH 01/12] Ext4: Fix extended timestamp encoding and decoding Theodore Ts'o <tytso@mit.edu> - 2015-11-29 03:50 +0100
            Re: [PATCH 01/12] Ext4: Fix extended timestamp encoding and decoding Arnd Bergmann <arnd@arndb.de> - 2015-11-29 22:40 +0100
              Re: [PATCH 01/12] Ext4: Fix extended timestamp encoding and decoding Theodore Ts'o <tytso@mit.edu> - 2015-11-30 15:20 +0100
                Re: [PATCH 01/12] Ext4: Fix extended timestamp encoding and decoding Arnd Bergmann <arnd@arndb.de> - 2015-11-30 15:40 +0100
                Re: [PATCH 01/12] Ext4: Fix extended timestamp encoding and decoding Elmar Stellnberger <estellnb@elstel.org> - 2015-11-30 16:00 +0100
        Re: [PATCH 01/12] Ext4: Fix extended timestamp encoding and decoding David Howells <dhowells@redhat.com> - 2015-11-26 16:30 +0100
    Re: [RFC][PATCH 00/12] Enhanced file stat system call Martin Steigerwald <martin@lichtvoll.de> - 2015-11-20 17:30 +0100
      Re: [RFC][PATCH 00/12] Enhanced file stat system call David Howells <dhowells@redhat.com> - 2015-11-20 17:30 +0100
        Re: [RFC][PATCH 00/12] Enhanced file stat system call Martin Steigerwald <martin@lichtvoll.de> - 2015-11-20 17:40 +0100
        Re: [RFC][PATCH 00/12] Enhanced file stat system call bfields@fieldses.org (J. Bruce Fields) - 2015-11-25 19:00 +0100
          Re: [RFC][PATCH 00/12] Enhanced file stat system call Andreas Dilger <adilger@dilger.ca> - 2015-11-25 20:40 +0100
      Re: [RFC][PATCH 00/12] Enhanced file stat system call Christoph Hellwig <hch@infradead.org> - 2015-11-24 09:20 +0100
        Re: [RFC][PATCH 00/12] Enhanced file stat system call Martin Steigerwald <martin@lichtvoll.de> - 2015-11-24 09:50 +0100
          Re: [RFC][PATCH 00/12] Enhanced file stat system call Christoph Hellwig <hch@infradead.org> - 2015-11-24 10:00 +0100
    Re: [RFC][PATCH 00/12] Enhanced file stat system call Casey Schaufler <casey@schaufler-ca.com> - 2015-11-20 18:00 +0100
      Re: [RFC][PATCH 00/12] Enhanced file stat system call Christoph Hellwig <hch@infradead.org> - 2015-11-24 09:20 +0100
        Re: [RFC][PATCH 00/12] Enhanced file stat system call Casey Schaufler <casey@schaufler-ca.com> - 2015-11-24 16:00 +0100
      Re: [RFC][PATCH 00/12] Enhanced file stat system call Andreas Dilger <adilger@dilger.ca> - 2015-11-24 17:30 +0100
    Re: [RFC][PATCH 00/12] Enhanced file stat system call Christoph Hellwig <hch@infradead.org> - 2015-11-24 09:20 +0100
      Re: [RFC][PATCH 00/12] Enhanced file stat system call David Howells <dhowells@redhat.com> - 2015-11-26 16:20 +0100
        Re: [RFC][PATCH 00/12] Enhanced file stat system call Andreas Dilger <adilger@dilger.ca> - 2015-11-26 23:10 +0100
    Re: [PATCH 03/12] statx: Add a system call to make enhanced file  info available Dave Chinner <david@fromorbit.com> - 2015-11-24 21:30 +0100

Page 2 of 2 — ← Prev page 1 [2]

#1276145

FromChristoph Hellwig <hch@infradead.org>
Date2015-11-24 09:20 +0100
Message-ID<qygZr-5z4-5@gated-at.bofh.it>
In reply to#1274225
On Fri, Nov 20, 2015 at 05:19:31PM +0100, Martin Steigerwald wrote:
> I know its mostly relevant for just for FAT32, but on any account rather than 
> trying to write 4 GiB and then file, it would be good to at some time get a 
> dialog at the beginning of the copy.

pathconf/fpathconf is supposed to handle that.  It's not super pretty
but part of Posix.  Linus hates it, but it might be time to give it
another try.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1276168

FromMartin Steigerwald <martin@lichtvoll.de>
Date2015-11-24 09:50 +0100
Message-ID<qyhsu-5Kj-19@gated-at.bofh.it>
In reply to#1276145
Am Dienstag, 24. November 2015, 00:13:08 CET schrieb Christoph Hellwig:
> On Fri, Nov 20, 2015 at 05:19:31PM +0100, Martin Steigerwald wrote:
> > I know its mostly relevant for just for FAT32, but on any account rather
> > than trying to write 4 GiB and then file, it would be good to at some
> > time get a dialog at the beginning of the copy.
> 
> pathconf/fpathconf is supposed to handle that.  It's not super pretty
> but part of Posix.  Linus hates it, but it might be time to give it
> another try.

It might be interesting for BTRFS as well, to be able to ask what amount of 
free space there currently is *at* a given path. Cause with BTRFS and 
Subvolumes this may differ between different paths. Even tough its not 
implemented yet, it may be possible in the future to have one subvolume with 
RAID 1 profile and one with RAID 0 profile.

That said an application wanting to make sure it can write a certain amount of 
data can use fallocate. And thats thats the only reliable way to ensure it, I 
know of. Which can become tedious for several files, but there is no principal 
problem with preallocating all files if their sizes are known. Even rsync or 
desktop environments could work like that. First fallocate everything, then, 
only if that succeeds, start actually copying data. Disadvantage: On aborted 
copies you have all files with their correct sizes and no easy indicates on 
where the copy stopped.

Thanks,
-- 
Martin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1276175

FromChristoph Hellwig <hch@infradead.org>
Date2015-11-24 10:00 +0100
Message-ID<qyhCa-5Ot-19@gated-at.bofh.it>
In reply to#1276168
On Tue, Nov 24, 2015 at 09:48:22AM +0100, Martin Steigerwald wrote:
> It might be interesting for BTRFS as well, to be able to ask what amount of 
> free space there currently is *at* a given path. Cause with BTRFS and 
> Subvolumes this may differ between different paths.

We can handle this trivial with the current statfs interface.  Take a
look at xfs_fs_statfs and xfs_qm_statvfs.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1274271

FromCasey Schaufler <casey@schaufler-ca.com>
Date2015-11-20 18:00 +0100
Message-ID<qwXcu-1li-25@gated-at.bofh.it>
In reply to#1274142

On 11/20/2015 6:54 AM, David Howells wrote:
> Implement new system calls to provide enhanced file stats and enhanced
> filesystem stats.  The patches can be found here:
>
> 	http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=xstat
>
>
> ===========
> DESCRIPTION
> ===========
>
> The third patch provides this new system call:
>
> 	long ret = statx(int dfd,
> 			 const char *filename,
> 			 unsigned atflag,
> 			 unsigned mask,
> 			 struct statx *buffer);
>
> This is an enhanced file stat function that provides a number of useful
> features, in summary:
>
>   (1) More information: creation time, data version number,
>       flags/attributes.  A subset of these is available through a number of
>       filesystems (such as CIFS, NFS, AFS, Ext4 and BTRFS).
>
>   (2) Lightweight stat (AT_NO_ATTR_SYNC): Ask for just those details of
>       interest, and allow a network fs to approximate anything not of
>       interest, without going to the server.
>
>   (3) Heavyweight stat (AT_FORCE_ATTR_SYNC): Force a network fs to flush
>       buffers and go to the server, even if it thinks its cached attributes
>       are up to date.
>
>   (4) Allow the filesystem to indicate what it can/cannot provide: A
>       filesystem can now say it doesn't support a standard stat feature if
>       that isn't available.
>
>   (5) Make the fields a consistent size on all arches, and make them large.
>
>   (6) Can be extended by using more request flags and using up the padding
>       space in the statx struct.

How about relevant xattrs? SELinux context, ACL, that sort of thing.
The fact that these are optional should be taken care of by (4).

>
> Note that no lstat() equivalent is required as that can be implemented
> through statx() with atflag == 0.  There is also no fstat() equivalent as
> that can be implemented through statx() with filename == NULL and the
> relevant fd passed as dfd.
>
>
> The seventh patch provides another new system call:
>
> 	long ret = fsinfo(int dfd,
> 			  const char *filename,
> 			  unsigned atflag,
> 			  unsigned request,
> 			  void *buffer);
>
> This is an enhanced filesystem stat and information retrieval function that
> provides more information, in summary:
>
>   (1) All the information provided by statfs() and more.  The fields are
>       made large.
>
>   (2) Provides information about timestamp range and resolution to
>       complement statx().
>
>   (3) Provides information about IOC flags supported in statx()'s return.
>
>   (4) Provides volume binary IDs and UUIDs.
>
>   (5) Provides the filesystem name according to the kernel as a string
>       (eg. "ext4" or "nfs3") in addition to the magic number.
>
>   (6) Provides information obtained from network filesystems, such as volume
>       and domain names.
>
>   (7) Has lots of spare space that can be used for future extenstions and a
>       bit mask indicating what was provided.
>
> Note that I've added a 'request' identifier.  This is to select the set of
> data to be returned.  The idea is that 'buffer' points to a fixed-size
> struct selected by request.  Currently only 0 is available and this refers
> to 'struct fsinfo'.  However, I could split up the buffer into say 3:
>
>   (0) statfs-type information
>
>   (1) Timestamp and IOC flags info.
>
>   (2) Network fs strings.
>
> However, some of this might be better retrieved through getxattr().
>
>
> =======
> TESTING
> =======
>
> Test programs are added into samples/statx/ by the appropriate patches.
>
> David
> ---
> David Howells (12):
>        Ext4: Fix extended timestamp encoding and decoding
>        statx: Provide IOC flags for Windows fs attributes
>        statx: Add a system call to make enhanced file info available
>        statx: AFS: Return enhanced file attributes
>        statx: Ext4: Return enhanced file attributes
>        statx: NFS: Return enhanced file attributes
>        statx: CIFS: Return enhanced attributes
>        fsinfo: Add a system call to make enhanced filesystem info available
>        fsinfo: Ext4: Return information through the filesystem info syscall
>        fsinfo: AFS: Return information through the filesystem info syscall
>        fsinfo: NFS: Return information through the filesystem info syscall
>        fsinfo: CIFS: Return information through the filesystem info syscall
>
>
>   arch/x86/entry/syscalls/syscall_32.tbl |    2
>   arch/x86/entry/syscalls/syscall_64.tbl |    2
>   fs/afs/inode.c                         |   23 ++
>   fs/afs/super.c                         |   39 ++++
>   fs/cifs/cifsfs.c                       |   25 +++
>   fs/cifs/cifsfs.h                       |    4
>   fs/cifs/cifsglob.h                     |    8 +
>   fs/cifs/dir.c                          |    2
>   fs/cifs/inode.c                        |  124 ++++++++++---
>   fs/cifs/netmisc.c                      |    4
>   fs/exportfs/expfs.c                    |    4
>   fs/ext4/ext4.h                         |   24 ++-
>   fs/ext4/file.c                         |    2
>   fs/ext4/inode.c                        |   31 +++
>   fs/ext4/namei.c                        |    2
>   fs/ext4/super.c                        |   39 ++++
>   fs/ext4/symlink.c                      |    2
>   fs/nfs/inode.c                         |   45 ++++-
>   fs/nfs/internal.h                      |    1
>   fs/nfs/nfs4super.c                     |    1
>   fs/nfs/super.c                         |   58 ++++++
>   fs/ntfs/time.h                         |    2
>   fs/stat.c                              |  305 +++++++++++++++++++++++++++++---
>   fs/statfs.c                            |  218 +++++++++++++++++++++++
>   include/linux/fs.h                     |    7 +
>   include/linux/stat.h                   |   14 +
>   include/linux/syscalls.h               |    6 +
>   include/linux/time64.h                 |    2
>   include/uapi/linux/fcntl.h             |    2
>   include/uapi/linux/fs.h                |    7 +
>   include/uapi/linux/stat.h              |  185 +++++++++++++++++++
>   samples/Makefile                       |    3
>   samples/statx/Makefile                 |   13 +
>   samples/statx/test-fsinfo.c            |  179 +++++++++++++++++++
>   samples/statx/test-statx.c             |  273 +++++++++++++++++++++++++++++
>   35 files changed, 1558 insertions(+), 100 deletions(-)
>   create mode 100644 samples/statx/Makefile
>   create mode 100644 samples/statx/test-fsinfo.c
>   create mode 100644 samples/statx/test-statx.c
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1276146

FromChristoph Hellwig <hch@infradead.org>
Date2015-11-24 09:20 +0100
Message-ID<qygZs-5z4-15@gated-at.bofh.it>
In reply to#1274271
On Fri, Nov 20, 2015 at 08:50:22AM -0800, Casey Schaufler wrote:
> How about relevant xattrs? SELinux context, ACL, that sort of thing.
> The fact that these are optional should be taken care of by (4).

Those are not simple, fixed size stat data and would make the system
call a giant mess.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1276538

FromCasey Schaufler <casey@schaufler-ca.com>
Date2015-11-24 16:00 +0100
Message-ID<qyney-130-3@gated-at.bofh.it>
In reply to#1276146
On 11/24/2015 12:15 AM, Christoph Hellwig wrote:
> On Fri, Nov 20, 2015 at 08:50:22AM -0800, Casey Schaufler wrote:
>> How about relevant xattrs? SELinux context, ACL, that sort of thing.
>> The fact that these are optional should be taken care of by (4).
> Those are not simple, fixed size stat data and would make the system
> call a giant mess.
>
I didn't say it would be easy. I do think that adding a system call
that only deals with simple, fixed size data is going to fall short
of solving "the problem".

Actually, a Smack label is fixed size (256 bytes). I suspect there
is a maximum for SELinux contexts as well. ACLs I'll grant you are
infinite.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1276617

FromAndreas Dilger <adilger@dilger.ca>
Date2015-11-24 17:30 +0100
Message-ID<qyoDE-262-29@gated-at.bofh.it>
In reply to#1274271

[Multipart message — attachments visible in raw view] — view raw

On Nov 20, 2015, at 9:50 AM, Casey Schaufler <casey@schaufler-ca.com> wrote:
> On 11/20/2015 6:54 AM, David Howells wrote:
>> Implement new system calls to provide enhanced file stats and enhanced
>> filesystem stats.  The patches can be found here:
>> 
>> 	http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=xstat
>> 
>> 
>> ===========
>> DESCRIPTION
>> ===========
>> 
>> The third patch provides this new system call:
>> 
>> 	long ret = statx(int dfd,
>> 			 const char *filename,
>> 			 unsigned atflag,
>> 			 unsigned mask,
>> 			 struct statx *buffer);
>> 
>> This is an enhanced file stat function that provides a number of useful
>> features, in summary:
>> 
>>  (1) More information: creation time, data version number,
>>      flags/attributes.  A subset of these is available through a number of
>>      filesystems (such as CIFS, NFS, AFS, Ext4 and BTRFS).
>> 
>>  (2) Lightweight stat (AT_NO_ATTR_SYNC): Ask for just those details of
>>      interest, and allow a network fs to approximate anything not of
>>      interest, without going to the server.
>> 
>>  (3) Heavyweight stat (AT_FORCE_ATTR_SYNC): Force a network fs to flush
>>      buffers and go to the server, even if it thinks its cached attributes
>>      are up to date.
>> 
>>  (4) Allow the filesystem to indicate what it can/cannot provide: A
>>      filesystem can now say it doesn't support a standard stat feature if
>>      that isn't available.
>> 
>>  (5) Make the fields a consistent size on all arches, and make them large.
>> 
>>  (6) Can be extended by using more request flags and using up the padding
>>      space in the statx struct.
> 
> How about relevant xattrs? SELinux context, ACL, that sort of thing.
> The fact that these are optional should be taken care of by (4).

Given that there are a wide variety of xattrs that different apps might be
interested in, this would probably be better served by an enhancement to
getxattr() or listxattr() to be able to retrieve a whole list of xattrs
at once, possibly with some wildcard support (e.g. "security.*") instead
of returning all or a specific subset of xattrs with statx() (which is
geared toward fixed-size attributes).

Cheers, Andreas


>> Note that no lstat() equivalent is required as that can be implemented
>> through statx() with atflag == 0.  There is also no fstat() equivalent as
>> that can be implemented through statx() with filename == NULL and the
>> relevant fd passed as dfd.
>> 
>> 
>> The seventh patch provides another new system call:
>> 
>> 	long ret = fsinfo(int dfd,
>> 			  const char *filename,
>> 			  unsigned atflag,
>> 			  unsigned request,
>> 			  void *buffer);
>> 
>> This is an enhanced filesystem stat and information retrieval function that
>> provides more information, in summary:
>> 
>>  (1) All the information provided by statfs() and more.  The fields are
>>      made large.
>> 
>>  (2) Provides information about timestamp range and resolution to
>>      complement statx().
>> 
>>  (3) Provides information about IOC flags supported in statx()'s return.
>> 
>>  (4) Provides volume binary IDs and UUIDs.
>> 
>>  (5) Provides the filesystem name according to the kernel as a string
>>      (eg. "ext4" or "nfs3") in addition to the magic number.
>> 
>>  (6) Provides information obtained from network filesystems, such as volume
>>      and domain names.
>> 
>>  (7) Has lots of spare space that can be used for future extenstions and a
>>      bit mask indicating what was provided.
>> 
>> Note that I've added a 'request' identifier.  This is to select the set of
>> data to be returned.  The idea is that 'buffer' points to a fixed-size
>> struct selected by request.  Currently only 0 is available and this refers
>> to 'struct fsinfo'.  However, I could split up the buffer into say 3:
>> 
>>  (0) statfs-type information
>> 
>>  (1) Timestamp and IOC flags info.
>> 
>>  (2) Network fs strings.
>> 
>> However, some of this might be better retrieved through getxattr().
>> 
>> 
>> =======
>> TESTING
>> =======
>> 
>> Test programs are added into samples/statx/ by the appropriate patches.
>> 
>> David
>> ---
>> David Howells (12):
>>       Ext4: Fix extended timestamp encoding and decoding
>>       statx: Provide IOC flags for Windows fs attributes
>>       statx: Add a system call to make enhanced file info available
>>       statx: AFS: Return enhanced file attributes
>>       statx: Ext4: Return enhanced file attributes
>>       statx: NFS: Return enhanced file attributes
>>       statx: CIFS: Return enhanced attributes
>>       fsinfo: Add a system call to make enhanced filesystem info available
>>       fsinfo: Ext4: Return information through the filesystem info syscall
>>       fsinfo: AFS: Return information through the filesystem info syscall
>>       fsinfo: NFS: Return information through the filesystem info syscall
>>       fsinfo: CIFS: Return information through the filesystem info syscall
>> 
>> 
>>  arch/x86/entry/syscalls/syscall_32.tbl |    2
>>  arch/x86/entry/syscalls/syscall_64.tbl |    2
>>  fs/afs/inode.c                         |   23 ++
>>  fs/afs/super.c                         |   39 ++++
>>  fs/cifs/cifsfs.c                       |   25 +++
>>  fs/cifs/cifsfs.h                       |    4
>>  fs/cifs/cifsglob.h                     |    8 +
>>  fs/cifs/dir.c                          |    2
>>  fs/cifs/inode.c                        |  124 ++++++++++---
>>  fs/cifs/netmisc.c                      |    4
>>  fs/exportfs/expfs.c                    |    4
>>  fs/ext4/ext4.h                         |   24 ++-
>>  fs/ext4/file.c                         |    2
>>  fs/ext4/inode.c                        |   31 +++
>>  fs/ext4/namei.c                        |    2
>>  fs/ext4/super.c                        |   39 ++++
>>  fs/ext4/symlink.c                      |    2
>>  fs/nfs/inode.c                         |   45 ++++-
>>  fs/nfs/internal.h                      |    1
>>  fs/nfs/nfs4super.c                     |    1
>>  fs/nfs/super.c                         |   58 ++++++
>>  fs/ntfs/time.h                         |    2
>>  fs/stat.c                              |  305 +++++++++++++++++++++++++++++---
>>  fs/statfs.c                            |  218 +++++++++++++++++++++++
>>  include/linux/fs.h                     |    7 +
>>  include/linux/stat.h                   |   14 +
>>  include/linux/syscalls.h               |    6 +
>>  include/linux/time64.h                 |    2
>>  include/uapi/linux/fcntl.h             |    2
>>  include/uapi/linux/fs.h                |    7 +
>>  include/uapi/linux/stat.h              |  185 +++++++++++++++++++
>>  samples/Makefile                       |    3
>>  samples/statx/Makefile                 |   13 +
>>  samples/statx/test-fsinfo.c            |  179 +++++++++++++++++++
>>  samples/statx/test-statx.c             |  273 +++++++++++++++++++++++++++++
>>  35 files changed, 1558 insertions(+), 100 deletions(-)
>>  create mode 100644 samples/statx/Makefile
>>  create mode 100644 samples/statx/test-fsinfo.c
>>  create mode 100644 samples/statx/test-statx.c
>> 
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at  http://www.tux.org/lkml/
>> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


Cheers, Andreas

[toc] | [prev] | [next] | [standalone]

#1276142

FromChristoph Hellwig <hch@infradead.org>
Date2015-11-24 09:20 +0100
Message-ID<qygZr-5z4-3@gated-at.bofh.it>
In reply to#1274142
Hi David,

from a quick look the statx bits looks fine in general.  I think Ted
last time had a problem with the IOC flag allocation, so you might
want to ping him.

But fsinfo with the multiplexer and the void pointer is just horrible.
What were you thinking there?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1278282

FromDavid Howells <dhowells@redhat.com>
Date2015-11-26 16:20 +0100
Message-ID<qz6uZ-6U1-15@gated-at.bofh.it>
In reply to#1276142
Christoph Hellwig <hch@infradead.org> wrote:

> from a quick look the statx bits looks fine in general.  I think Ted
> last time had a problem with the IOC flag allocation, so you might
> want to ping him.

Yeah - he commented on that.

> But fsinfo with the multiplexer and the void pointer is just horrible.
> What were you thinking there?

I think the fsinfo data struct probably wants splitting up.  Now this could be
done in a number of ways, including:

 (1) By adding multiple syscalls (statfsx, fsinfo, netfsinfo, ...) but each
     one needs a bit in the kernel to handle the basics (path/fd lookup,
     security check, buffer allocation and freeing, ...) which could all be in
     common - hence the mux method.

 (2) Adding an argument to the fsinfo syscall since it has at least one
     syscall argument spare.

 (3) Offloading some of the bits to standardised xattr calls.  The large
     string fields (domain name, volume name, ...) would seem to be obvious
     candidates for this.

Given that the core VFS gets to manage the contents of the buffer, it
shouldn't be as controversial as pioctl().

David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1278465

FromAndreas Dilger <adilger@dilger.ca>
Date2015-11-26 23:10 +0100
Message-ID<qzcTM-2Dt-19@gated-at.bofh.it>
In reply to#1278282

[Multipart message — attachments visible in raw view] — view raw

On Nov 26, 2015, at 8:19 AM, David Howells <dhowells@redhat.com> wrote:
> 
> Christoph Hellwig <hch@infradead.org> wrote:
> 
>> from a quick look the statx bits looks fine in general.  I think Ted
>> last time had a problem with the IOC flag allocation, so you might
>> want to ping him.
> 
> Yeah - he commented on that.
> 
>> But fsinfo with the multiplexer and the void pointer is just horrible.
>> What were you thinking there?
> 
> I think the fsinfo data struct probably wants splitting up.

Could we separate the statx() and fsinfo() submissions so that this doesn't
block statx() landing indefinitely?  I think people are generally in support
of statx() as it is today, and it's been _sooo_ long in coming that I'd hate
to see it delayed further.  The statx() syscall definitely has value without
fsinfo() to improve the life of network filesystems.

Cheers, Andreas

>  Now this could be
> done in a number of ways, including:
> 
> (1) By adding multiple syscalls (statfsx, fsinfo, netfsinfo, ...) but each
>     one needs a bit in the kernel to handle the basics (path/fd lookup,
>     security check, buffer allocation and freeing, ...) which could all be in
>     common - hence the mux method.
> 
> (2) Adding an argument to the fsinfo syscall since it has at least one
>     syscall argument spare.
> 
> (3) Offloading some of the bits to standardised xattr calls.  The large
>     string fields (domain name, volume name, ...) would seem to be obvious
>     candidates for this.
> 
> Given that the core VFS gets to manage the contents of the buffer, it
> shouldn't be as controversial as pioctl().
> 
> David
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


Cheers, Andreas

[toc] | [prev] | [next] | [standalone]

#1276750 — Re: [PATCH 03/12] statx: Add a system call to make enhanced file info available

FromDave Chinner <david@fromorbit.com>
Date2015-11-24 21:30 +0100
SubjectRe: [PATCH 03/12] statx: Add a system call to make enhanced file info available
Message-ID<qysnU-4vl-17@gated-at.bofh.it>
In reply to#1274142
On Fri, Nov 20, 2015 at 02:54:57PM +0000, David Howells wrote:
> The defined bits in st_ioc_flags are the usual FS_xxx_FL, plus some extra
> flags that might be supplied by the filesystem.  Note that Ext4 returns
> flags outside of {EXT4,FS}_FL_USER_VISIBLE in response to FS_IOC_GETFLAGS.
> Should {EXT4,FS}_FL_USER_VISIBLE be extended to cover them?  Or should the
> extra flags be suppressed?

Quite frankly, we should not expose flags owned by a filesystem like
this. Create a new set of flagsi that are exposed by the syscall,
and every filesystem is responsible for translating their internal
flag values to the syscall flag values....

> The defined bits in the st_information field give local system data on a
> file, how it is accessed, where it is and what it does:
> 
> 	STATX_INFO_ENCRYPTED		File is encrypted
> 	STATX_INFO_TEMPORARY		File is temporary (NTFS/CIFS/deleted)
> 	STATX_INFO_FABRICATED		File was made up by filesystem
> 	STATX_INFO_KERNEL_API		File is kernel API (eg: procfs/sysfs)
> 	STATX_INFO_REMOTE		File is remote
> 	STATX_INFO_OFFLINE		File is offline (CIFS)
> 	STATX_INFO_AUTOMOUNT		Dir is automount trigger
> 	STATX_INFO_AUTODIR		Dir provides unlisted automounts
> 	STATX_INFO_NONSYSTEM_OWNERSHIP	File has non-system ownership details
> 	STATX_INFO_REPARSE_POINT	File is reparse point (NTFS/CIFS)

	STATX_INFO_XATTR		File/dir has extended attrs

... just like these STATX_INFO flags are filesystem independent...

And, FWIW, I'd like to see more than one local filesystem supported
in the initial patchset (e.g. btrfs) and also have all their
inode/fs flags exposed so we don't end up encoding weird
ext4-specific feature quirks into the API.....

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.kernel

csiph-web