All of lore.kernel.org
 help / color / mirror / Atom feed
* [RFC][PATCH 0/4] Enhanced file stat system call
@ 2016-11-17 13:34 David Howells
  2016-11-17 13:35 ` [PATCH 1/4] statx: Add a system call to make enhanced file info available David Howells
                   ` (7 more replies)
  0 siblings, 8 replies; 52+ messages in thread
From: David Howells @ 2016-11-17 13:34 UTC (permalink / raw)
  To: linux-fsdevel; +Cc: dhowells, linux-kernel


Implement a new system call to provide enhanced file stats.  The patches can
be found here:

	http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=xstat


===========
DESCRIPTION
===========

The first 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 and attributes.
     A subset of these is available through a number of filesystems (such
     as CIFS, NFS, AFS, Ext4 and BTRFS).

 (2) Lightweight stat (AT_STATX_DONT_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_STATX_FORCE_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.

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.


=======
TESTING
=======

A test program is added into samples/statx/ by the first patch.

David
---
David Howells (4):
      statx: Add a system call to make enhanced file info available
      statx: Ext4: Return enhanced file attributes
      statx: NFS: Return enhanced file attributes
      statx: AFS: Return enhanced file attributes


 arch/x86/entry/syscalls/syscall_32.tbl |    1 
 arch/x86/entry/syscalls/syscall_64.tbl |    1 
 fs/afs/inode.c                         |   21 ++
 fs/exportfs/expfs.c                    |    4 
 fs/ext4/ext4.h                         |    2 
 fs/ext4/file.c                         |    2 
 fs/ext4/inode.c                        |   38 ++++
 fs/ext4/namei.c                        |    2 
 fs/ext4/symlink.c                      |    2 
 fs/nfs/inode.c                         |   41 ++++
 fs/stat.c                              |  294 +++++++++++++++++++++++++++++---
 include/linux/fs.h                     |    5 -
 include/linux/stat.h                   |   19 +-
 include/linux/syscalls.h               |    3 
 include/uapi/linux/fcntl.h             |    2 
 include/uapi/linux/stat.h              |  124 +++++++++++++
 samples/Kconfig                        |    5 +
 samples/Makefile                       |    3 
 samples/statx/Makefile                 |   10 +
 samples/statx/test-statx.c             |  248 +++++++++++++++++++++++++++
 20 files changed, 771 insertions(+), 56 deletions(-)
 create mode 100644 samples/statx/Makefile
 create mode 100644 samples/statx/test-statx.c

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [PATCH 1/4] statx: Add a system call to make enhanced file info available
  2016-11-17 13:34 [RFC][PATCH 0/4] Enhanced file stat system call David Howells
@ 2016-11-17 13:35 ` David Howells
  2016-11-17 18:39   ` Jeff Layton
                     ` (5 more replies)
  2016-11-17 13:35 ` [PATCH 2/4] statx: Ext4: Return enhanced file attributes David Howells
                   ` (6 subsequent siblings)
  7 siblings, 6 replies; 52+ messages in thread
From: David Howells @ 2016-11-17 13:35 UTC (permalink / raw)
  To: linux-fsdevel; +Cc: dhowells, linux-kernel

Add a system call to make extended file information available, including
file creation, data version and some attribute flags where available
through the underlying filesystem.


========
OVERVIEW
========

The idea was initially proposed as a set of xattrs that could be retrieved
with getxattr(), but the general preferance proved to be for a new syscall
with an extended stat structure.

This has a number of uses:

 (1) Better support for the y2038 problem [Arnd Bergmann].

 (2) Creation time: The SMB protocol carries the creation time, which could
     be exported by Samba, which will in turn help CIFS make use of
     FS-Cache as that can be used for coherency data.

     This is also specified in NFSv4 as a recommended attribute and could
     be exported by NFSD [Steve French].

 (3) Lightweight stat: Ask for just those details of interest, and allow a
     netfs (such as NFS) to approximate anything not of interest, possibly
     without going to the server [Trond Myklebust, Ulrich Drepper, Andreas
     Dilger].

 (4) Heavyweight stat: Force a netfs to go to the server, even if it thinks
     its cached attributes are up to date [Trond Myklebust].

 (5) Data version number: Could be used by userspace NFS servers [Aneesh
     Kumar].

     Can also be used to modify fill_post_wcc() in NFSD which retrieves
     i_version directly, but has just called vfs_getattr().  It could get
     it from the kstat struct if it used vfs_xgetattr() instead.

 (6) BSD stat compatibility: Including more fields from the BSD stat such
     as creation time (st_btime) and inode generation number (st_gen)
     [Jeremy Allison, Bernd Schubert].

 (7) Inode generation number: Useful for FUSE and userspace NFS servers
     [Bernd Schubert].  This was asked for but later deemed unnecessary
     with the open-by-handle capability available

 (8) Extra coherency data may be useful in making backups [Andreas Dilger].

 (9) 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, so if, for instance, inode numbers or UIDs don't
     exist or are fabricated locally...

(10) Make the fields a consistent size on all arches and make them large.

(11) Store a 16-byte volume ID in the superblock that can be returned in
     struct xstat [Steve French].

(12) Include granularity fields in the time data to indicate the
     granularity of each of the times (NFSv4 time_delta) [Steve French].

(13) FS_IOC_GETFLAGS value.  These could be translated to BSD's st_flags.
     Note that the Linux IOC flags are a mess and filesystems such as Ext4
     define flags that aren't in linux/fs.h, so translation in the kernel
     may be a necessity (or, possibly, we provide the filesystem type too).

(14) Mask of features available on file (eg: ACLs, seclabel) [Brad Boyer,
     Michael Kerrisk].

(15) Spare space, request flags and information flags are provided for
     future expansion.

Note that not all of the above are implemented here.


===============
NEW SYSTEM CALL
===============

The new system call is:

	int ret = statx(int dfd,
			const char *filename,
			unsigned int flags,
			unsigned int mask,
			struct statx *buffer);

The dfd, filename and flags parameters indicate the file to query.  There
is no equivalent of lstat() as that can be emulated with statx() by passing
AT_SYMLINK_NOFOLLOW in flags.  There is also no equivalent of fstat() as
that can be emulated by passing a NULL filename to statx() with the fd of
interest in dfd.

AT_STATX_FORCE_SYNC can be set in flags.  This will require a network
filesystem to synchronise its attributes with the server.

AT_STATX_DONT_SYNC can be set in flags.  This will suppress synchronisation
with the server in a network filesystem.  The resulting values should be
considered approximate.

If neither AT_STATX_*_SYNC flag is set, the behaviour is the default for
stat() on that filesystem.

mask is a bitmask indicating the fields in struct statx that are of
interest to the caller.  The user should set this to STATX_BASIC_STATS to
get the basic set returned by stat().  It should be note that asking for
more information may entail more I/O operations.

buffer points to the destination for the data.  This must be 256 bytes in
size.


======================
MAIN ATTRIBUTES RECORD
======================

The following structures are defined in which to return the main attribute
set:

	struct statx {
		__u32	stx_mask;
		__u32	stx_blksize;
		__u64	stx_attributes;
		__u32	stx_nlink;
		__u32	stx_uid;
		__u32	stx_gid;
		__u16	stx_mode;
		__u16	__spare0[1];
		__u64	stx_ino;
		__u64	stx_size;
		__u64	stx_blocks;
		__u64	stx_version;
		__s64	stx_atime;
		__s64	stx_btime;
		__s64	stx_ctime;
		__s64	stx_mtime;
		__s32	stx_atime_ns;
		__s32	stx_btime_ns;
		__s32	stx_ctime_ns;
		__s32	stx_mtime_ns;
		__u32	stx_rdev_major;
		__u32	stx_rdev_minor;
		__u32	stx_dev_major;
		__u32	stx_dev_minor;
		__u64	__spare1[16];
	};

The defined bits in request_mask and stx_mask are:

	STATX_TYPE		Want/got stx_mode & S_IFMT
	STATX_MODE		Want/got stx_mode & ~S_IFMT
	STATX_NLINK		Want/got stx_nlink
	STATX_UID		Want/got stx_uid
	STATX_GID		Want/got stx_gid
	STATX_ATIME		Want/got stx_atime{,_ns}
	STATX_MTIME		Want/got stx_mtime{,_ns}
	STATX_CTIME		Want/got stx_ctime{,_ns}
	STATX_INO		Want/got stx_ino
	STATX_SIZE		Want/got stx_size
	STATX_BLOCKS		Want/got stx_blocks
	STATX_BASIC_STATS	[The stuff in the normal stat struct]
	STATX_BTIME		Want/got stx_btime{,_ns}
	STATX_VERSION		Want/got stx_version
	STATX_ALL		[All currently available stuff]

stx_btime is the file creation time; stx_version is the data version number
(i_version); stx_mask is a bitmask indicating the data provided; and
__spares*[] are where as-yet undefined fields can be placed.

Time fields are split into separate seconds and nanoseconds fields to make
packing easier and the granularities can be queried with the filesystem
info system call.  Note that times will be negative if before 1970; in such
a case, the nanosecond fields will also be negative if not zero.

The bits defined in the stx_attributes field convey information about a
file, how it is accessed, where it is and what it does.  The following
attributes map to FS_*_FL flags and are the same numerical value:

	STATX_ATTR_COMPRESSED		File is compressed by the fs
	STATX_ATTR_IMMUTABLE		File is marked immutable
	STATX_ATTR_APPEND		File is append-only
	STATX_ATTR_NODUMP		File is not to be dumped
	STATX_ATTR_ENCRYPTED		File requires key to decrypt in fs

The supported flags are listed by:

	STATX_ATTR_FS_IOC_FLAGS

[Are any other IOC flags of sufficient general interest to be exposed
through this interface?]

New flags include:

	STATX_ATTR_NONUNIX_OWNERSHIP	File doesn't have Unixy ownership
	STATX_ATTR_HAS_ACL		File has an ACL
	STATX_ATTR_KERNEL_API		File is kernel API (eg: procfs/sysfs)
	STATX_ATTR_REMOTE		File is remote and needs network
	STATX_ATTR_FABRICATED		File was made up by fs
	STATX_ATTR_AUTOMOUNT		Object is an automount trigger
	STATX_ATTR_UNLISTED_DENTS	Dir: Lookup may find files getdents doesn't

These are for the use of GUI tools that might want to mark files specially,
depending on what they are.

Fields in struct statx come in a number of classes:

 (0) stx_dev_*, stx_blksize.

     These are local system information and are always available.

 (1) stx_mode, stx_nlinks, stx_uid, stx_gid, stx_[amc]time*, stx_ino,
     stx_size, stx_blocks.

     These will be returned whether the caller asks for them or not.  The
     corresponding bits in stx_mask will be set to indicate whether they
     actually have valid values.

     If the caller didn't ask for them, then they may be approximated.  For
     example, NFS won't waste any time updating them from the server,
     unless as a byproduct of updating something requested.

     If the values don't actually exist for the underlying object (such as
     UID or GID on a DOS file), then the bit won't be set in the stx_mask,
     even if the caller asked for the value.  In such a case, the returned
     value will be a fabrication.

     Note that there are instances where the type might not be valid, for
     instance Windows reparse points.

 (2) stx_rdev_*.

     This will be set only if stx_mode indicates we're looking at a
     blockdev or a chardev, otherwise will be 0.

 (3) stx_btime*, stx_version.

     Similar to (1), except these will be set to 0 if they don't exist.


=======
TESTING
=======

The following test program can be used to test the statx system call:

	samples/statx/test-statx.c

Just compile and run, passing it paths to the files you want to examine.
The file is built automatically if CONFIG_SAMPLES is enabled.

Here's some example output.  Firstly, an NFS directory that crosses to
another FSID.  Note that the FABRICATED and AUTOMOUNT info flags are set.
The former because the directory is invented locally as we don't see the
underlying dir on the server, the latter because transiting this directory
will cause d_automount to be invoked by the VFS.

	[root@andromeda tmp]# ./samples/statx/test-statx -A /warthog/data
	statx(/warthog/data) = 0
	results=17ff
	  Size: 4096            Blocks: 8          IO Block: 1048576  directory
	Device: 00:26           Inode: 1703937     Links: 124
	Access: (3777/drwxrwxrwx)  Uid:     0   Gid:  4041
	Access: 2016-11-10 15:52:11.219935864+0000
	Modify: 2016-11-10 08:07:32.482314928+0000
	Change: 2016-11-10 08:07:32.482314928+0000
	Data version: 58242ac41cbf8ab0h
	Attributes: 000000000000e000 (-------- -------- -------- -------- -------- -------- mfr----- --------)
	IO-blocksize: blksize=1048576

Secondly, the result of automounting on that directory.

	[root@andromeda tmp]# ./samples/statx/test-statx /warthog/data
	statx(/warthog/data) = 0
	results=17ff
	  Size: 4096            Blocks: 8          IO Block: 1048576  directory
	Device: 00:27           Inode: 2           Links: 124
	Access: (3777/drwxrwxrwx)  Uid:     0   Gid:  4041
	Access: 2016-11-10 15:52:11.219935864+0000
	Modify: 2016-11-10 08:07:32.482314928+0000
	Change: 2016-11-10 08:07:32.482314928+0000
	Data version: 58242ac41cbf8ab0h
	Attributes: 0000000000002000 (-------- -------- -------- -------- -------- -------- --r----- --------)
	IO-blocksize: blksize=1048576

Signed-off-by: David Howells <dhowells@redhat.com>
---

 arch/x86/entry/syscalls/syscall_32.tbl |    1 
 arch/x86/entry/syscalls/syscall_64.tbl |    1 
 fs/exportfs/expfs.c                    |    4 
 fs/stat.c                              |  294 +++++++++++++++++++++++++++++---
 include/linux/fs.h                     |    5 -
 include/linux/stat.h                   |   19 +-
 include/linux/syscalls.h               |    3 
 include/uapi/linux/fcntl.h             |    2 
 include/uapi/linux/stat.h              |  124 +++++++++++++
 samples/Kconfig                        |    5 +
 samples/Makefile                       |    3 
 samples/statx/Makefile                 |   10 +
 samples/statx/test-statx.c             |  248 +++++++++++++++++++++++++++
 13 files changed, 679 insertions(+), 40 deletions(-)
 create mode 100644 samples/statx/Makefile
 create mode 100644 samples/statx/test-statx.c

diff --git a/arch/x86/entry/syscalls/syscall_32.tbl b/arch/x86/entry/syscalls/syscall_32.tbl
index 2b3618542544..9ba050fe47f3 100644
--- a/arch/x86/entry/syscalls/syscall_32.tbl
+++ b/arch/x86/entry/syscalls/syscall_32.tbl
@@ -389,3 +389,4 @@
 380	i386	pkey_mprotect		sys_pkey_mprotect
 381	i386	pkey_alloc		sys_pkey_alloc
 382	i386	pkey_free		sys_pkey_free
+383	i386	statx			sys_statx
diff --git a/arch/x86/entry/syscalls/syscall_64.tbl b/arch/x86/entry/syscalls/syscall_64.tbl
index e93ef0b38db8..5aef183e2f85 100644
--- a/arch/x86/entry/syscalls/syscall_64.tbl
+++ b/arch/x86/entry/syscalls/syscall_64.tbl
@@ -338,6 +338,7 @@
 329	common	pkey_mprotect		sys_pkey_mprotect
 330	common	pkey_alloc		sys_pkey_alloc
 331	common	pkey_free		sys_pkey_free
+332	common	statx			sys_statx
 
 #
 # x32-specific system call numbers start at 512 to avoid cache impact
diff --git a/fs/exportfs/expfs.c b/fs/exportfs/expfs.c
index a4b531be9168..2acc31751248 100644
--- a/fs/exportfs/expfs.c
+++ b/fs/exportfs/expfs.c
@@ -299,7 +299,9 @@ static int get_name(const struct path *path, char *name, struct dentry *child)
 	 * filesystem supports 64-bit inode numbers.  So we need to
 	 * actually call ->getattr, not just read i_ino:
 	 */
-	error = vfs_getattr_nosec(&child_path, &stat);
+	stat.query_flags = 0;
+	stat.request_mask = STATX_BASIC_STATS;
+	error = vfs_xgetattr_nosec(&child_path, &stat);
 	if (error)
 		return error;
 	buffer.ino = stat.ino;
diff --git a/fs/stat.c b/fs/stat.c
index bc045c7994e1..78c0a5086038 100644
--- a/fs/stat.c
+++ b/fs/stat.c
@@ -18,6 +18,15 @@
 #include <asm/uaccess.h>
 #include <asm/unistd.h>
 
+/**
+ * generic_fillattr - Fill in the basic attributes from the inode struct
+ * @inode: Inode to use as the source
+ * @stat: Where to fill in the attributes
+ *
+ * Fill in the basic attributes in the kstat structure from data that's to be
+ * found on the VFS inode structure.  This is the default if no getattr inode
+ * operation is supplied.
+ */
 void generic_fillattr(struct inode *inode, struct kstat *stat)
 {
 	stat->dev = inode->i_sb->s_dev;
@@ -27,87 +36,189 @@ void generic_fillattr(struct inode *inode, struct kstat *stat)
 	stat->uid = inode->i_uid;
 	stat->gid = inode->i_gid;
 	stat->rdev = inode->i_rdev;
-	stat->size = i_size_read(inode);
-	stat->atime = inode->i_atime;
 	stat->mtime = inode->i_mtime;
 	stat->ctime = inode->i_ctime;
-	stat->blksize = (1 << inode->i_blkbits);
+	stat->size = i_size_read(inode);
 	stat->blocks = inode->i_blocks;
-}
+	stat->blksize = 1 << inode->i_blkbits;
 
+	stat->result_mask |= STATX_BASIC_STATS;
+	if (IS_NOATIME(inode))
+		stat->result_mask &= ~STATX_ATIME;
+	else
+		stat->atime = inode->i_atime;
+
+	if (IS_AUTOMOUNT(inode))
+		stat->attributes |= STATX_ATTR_AUTOMOUNT;
+}
 EXPORT_SYMBOL(generic_fillattr);
 
 /**
- * vfs_getattr_nosec - getattr without security checks
+ * vfs_xgetattr_nosec - getattr without security checks
  * @path: file to get attributes from
  * @stat: structure to return attributes in
  *
  * Get attributes without calling security_inode_getattr.
  *
- * Currently the only caller other than vfs_getattr is internal to the
- * filehandle lookup code, which uses only the inode number and returns
- * no attributes to any user.  Any other code probably wants
- * vfs_getattr.
+ * Currently the only caller other than vfs_xgetattr is internal to the
+ * filehandle lookup code, which uses only the inode number and returns no
+ * attributes to any user.  Any other code probably wants vfs_xgetattr.
+ *
+ * The caller must set stat->request_mask to indicate what they want and
+ * stat->query_flags to indicate whether the server should be queried.
  */
-int vfs_getattr_nosec(struct path *path, struct kstat *stat)
+int vfs_xgetattr_nosec(struct path *path, struct kstat *stat)
 {
 	struct inode *inode = d_backing_inode(path->dentry);
 
+	stat->query_flags &= ~KSTAT_QUERY_FLAGS;
+
+	stat->result_mask = 0;
+	stat->attributes = 0;
 	if (inode->i_op->getattr)
 		return inode->i_op->getattr(path->mnt, path->dentry, stat);
 
 	generic_fillattr(inode, stat);
 	return 0;
 }
+EXPORT_SYMBOL(vfs_xgetattr_nosec);
 
-EXPORT_SYMBOL(vfs_getattr_nosec);
-
-int vfs_getattr(struct path *path, struct kstat *stat)
+/*
+ * vfs_xgetattr - Get the enhanced basic attributes of a file
+ * @path: The file of interest
+ * @stat: Where to return the statistics
+ *
+ * Ask the filesystem for a file's attributes.  The caller must have preset
+ * stat->request_mask and stat->query_flags to indicate what they want.
+ *
+ * If the file is remote, the filesystem can be forced to update the attributes
+ * from the backing store by passing AT_FORCE_ATTR_SYNC in query_flags or can
+ * suppress the update by passing AT_NO_ATTR_SYNC.
+ *
+ * Bits must have been set in stat->request_mask to indicate which attributes
+ * the caller wants retrieving.  Any such attribute not requested may be
+ * returned anyway, but the value may be approximate, and, if remote, may not
+ * have been synchronised with the server.
+ *
+ * 0 will be returned on success, and a -ve error code if unsuccessful.
+ */
+int vfs_xgetattr(struct path *path, struct kstat *stat)
 {
 	int retval;
 
 	retval = security_inode_getattr(path);
 	if (retval)
 		return retval;
-	return vfs_getattr_nosec(path, stat);
+	return vfs_xgetattr_nosec(path, stat);
 }
+EXPORT_SYMBOL(vfs_xgetattr);
 
+/**
+ * vfs_getattr - Get the basic attributes of a file
+ * @path: The file of interest
+ * @stat: Where to return the statistics
+ *
+ * Ask the filesystem for a file's attributes.  If remote, the filesystem isn't
+ * forced to update its files from the backing store.  Only the basic set of
+ * attributes will be retrieved; anyone wanting more must use vfs_xgetattr(),
+ * as must anyone who wants to force attributes to be sync'd with the server.
+ *
+ * 0 will be returned on success, and a -ve error code if unsuccessful.
+ */
+int vfs_getattr(struct path *path, struct kstat *stat)
+{
+	stat->query_flags = 0;
+	stat->request_mask = STATX_BASIC_STATS;
+	return vfs_xgetattr(path, stat);
+}
 EXPORT_SYMBOL(vfs_getattr);
 
-int vfs_fstat(unsigned int fd, struct kstat *stat)
+/**
+ * vfs_fstatx - Get the enhanced basic attributes by file descriptor
+ * @fd: The file descriptor referring to the file of interest
+ * @stat: The result structure to fill in.
+ *
+ * This function is a wrapper around vfs_xgetattr().  The main difference is
+ * that it uses a file descriptor to determine the file location.
+ *
+ * The caller must have preset stat->query_flags and stat->request_mask as for
+ * vfs_xgetattr().
+ *
+ * 0 will be returned on success, and a -ve error code if unsuccessful.
+ */
+int vfs_fstatx(unsigned int fd, struct kstat *stat)
 {
 	struct fd f = fdget_raw(fd);
 	int error = -EBADF;
 
 	if (f.file) {
-		error = vfs_getattr(&f.file->f_path, stat);
+		error = vfs_xgetattr(&f.file->f_path, stat);
 		fdput(f);
 	}
 	return error;
 }
+EXPORT_SYMBOL(vfs_fstatx);
+
+/**
+ * vfs_fstat - Get basic attributes by file descriptor
+ * @fd: The file descriptor referring to the file of interest
+ * @stat: The result structure to fill in.
+ *
+ * This function is a wrapper around vfs_getattr().  The main difference is
+ * that it uses a file descriptor to determine the file location.
+ *
+ * 0 will be returned on success, and a -ve error code if unsuccessful.
+ */
+int vfs_fstat(unsigned int fd, struct kstat *stat)
+{
+	stat->query_flags = 0;
+	stat->request_mask = STATX_BASIC_STATS;
+	return vfs_fstatx(fd, stat);
+}
 EXPORT_SYMBOL(vfs_fstat);
 
-int vfs_fstatat(int dfd, const char __user *filename, struct kstat *stat,
-		int flag)
+/**
+ * vfs_statx - Get basic and extra attributes by filename
+ * @dfd: A file descriptor representing the base dir for a relative filename
+ * @filename: The name of the file of interest
+ * @flags: Flags to control the query
+ * @stat: The result structure to fill in.
+ *
+ * This function is a wrapper around vfs_xgetattr().  The main difference is
+ * that it uses a filename and base directory to determine the file location.
+ * Additionally, the addition of AT_SYMLINK_NOFOLLOW to flags will prevent a
+ * symlink at the given name from being referenced.
+ *
+ * The caller must have preset stat->request_mask as for vfs_xgetattr().  The
+ * flags are also used to load up stat->query_flags.
+ *
+ * 0 will be returned on success, and a -ve error code if unsuccessful.
+ */
+int vfs_statx(int dfd, const char __user *filename, int flags,
+	      struct kstat *stat)
 {
 	struct path path;
 	int error = -EINVAL;
-	unsigned int lookup_flags = 0;
+	unsigned int lookup_flags = LOOKUP_FOLLOW | LOOKUP_AUTOMOUNT;
 
-	if ((flag & ~(AT_SYMLINK_NOFOLLOW | AT_NO_AUTOMOUNT |
-		      AT_EMPTY_PATH)) != 0)
-		goto out;
+	if ((flags & ~(AT_SYMLINK_NOFOLLOW | AT_NO_AUTOMOUNT |
+		       AT_EMPTY_PATH | KSTAT_QUERY_FLAGS)) != 0)
+		return -EINVAL;
 
-	if (!(flag & AT_SYMLINK_NOFOLLOW))
-		lookup_flags |= LOOKUP_FOLLOW;
-	if (flag & AT_EMPTY_PATH)
+	if (flags & AT_SYMLINK_NOFOLLOW)
+		lookup_flags &= ~LOOKUP_FOLLOW;
+	if (flags & AT_NO_AUTOMOUNT)
+		lookup_flags &= ~LOOKUP_AUTOMOUNT;
+	if (flags & AT_EMPTY_PATH)
 		lookup_flags |= LOOKUP_EMPTY;
+	stat->query_flags = flags;
+
 retry:
 	error = user_path_at(dfd, filename, lookup_flags, &path);
 	if (error)
 		goto out;
 
-	error = vfs_getattr(&path, stat);
+	error = vfs_xgetattr(&path, stat);
 	path_put(&path);
 	if (retry_estale(error, lookup_flags)) {
 		lookup_flags |= LOOKUP_REVAL;
@@ -116,17 +227,65 @@ int vfs_fstatat(int dfd, const char __user *filename, struct kstat *stat,
 out:
 	return error;
 }
+EXPORT_SYMBOL(vfs_statx);
+
+/**
+ * vfs_fstatat - Get basic attributes by filename
+ * @dfd: A file descriptor representing the base dir for a relative filename
+ * @filename: The name of the file of interest
+ * @flags: Flags to control the query
+ * @stat: The result structure to fill in.
+ *
+ * This function is a wrapper around vfs_statx().  The difference is that it
+ * preselects basic stats only.  The flags are used to load up
+ * stat->query_flags in addition to indicating symlink handling during path
+ * resolution.
+ *
+ * 0 will be returned on success, and a -ve error code if unsuccessful.
+ */
+int vfs_fstatat(int dfd, const char __user *filename, struct kstat *stat,
+		int flags)
+{
+	stat->request_mask = STATX_BASIC_STATS;
+	return vfs_statx(dfd, filename, flags, stat);
+}
 EXPORT_SYMBOL(vfs_fstatat);
 
-int vfs_stat(const char __user *name, struct kstat *stat)
+/**
+ * vfs_stat - Get basic attributes by filename
+ * @filename: The name of the file of interest
+ * @stat: The result structure to fill in.
+ *
+ * This function is a wrapper around vfs_statx().  The difference is that it
+ * preselects basic stats only, terminal symlinks are followed regardless and a
+ * remote filesystem can't be forced to query the server.  If such is desired,
+ * vfs_statx() should be used instead.
+ *
+ * 0 will be returned on success, and a -ve error code if unsuccessful.
+ */
+int vfs_stat(const char __user *filename, struct kstat *stat)
 {
-	return vfs_fstatat(AT_FDCWD, name, stat, 0);
+	stat->request_mask = STATX_BASIC_STATS;
+	return vfs_statx(AT_FDCWD, filename, 0, stat);
 }
 EXPORT_SYMBOL(vfs_stat);
 
+/**
+ * vfs_lstat - Get basic attrs by filename, without following terminal symlink
+ * @filename: The name of the file of interest
+ * @stat: The result structure to fill in.
+ *
+ * This function is a wrapper around vfs_statx().  The difference is that it
+ * preselects basic stats only, terminal symlinks are note followed regardless
+ * and a remote filesystem can't be forced to query the server.  If such is
+ * desired, vfs_statx() should be used instead.
+ *
+ * 0 will be returned on success, and a -ve error code if unsuccessful.
+ */
 int vfs_lstat(const char __user *name, struct kstat *stat)
 {
-	return vfs_fstatat(AT_FDCWD, name, stat, AT_SYMLINK_NOFOLLOW);
+	stat->request_mask = STATX_BASIC_STATS;
+	return vfs_statx(AT_FDCWD, name, AT_SYMLINK_NOFOLLOW, stat);
 }
 EXPORT_SYMBOL(vfs_lstat);
 
@@ -141,7 +300,7 @@ static int cp_old_stat(struct kstat *stat, struct __old_kernel_stat __user * sta
 {
 	static int warncount = 5;
 	struct __old_kernel_stat tmp;
-	
+
 	if (warncount > 0) {
 		warncount--;
 		printk(KERN_WARNING "VFS: Warning: %s using old stat() call. Recompile your binary.\n",
@@ -166,7 +325,7 @@ static int cp_old_stat(struct kstat *stat, struct __old_kernel_stat __user * sta
 #if BITS_PER_LONG == 32
 	if (stat->size > MAX_NON_LFS)
 		return -EOVERFLOW;
-#endif	
+#endif
 	tmp.st_size = stat->size;
 	tmp.st_atime = stat->atime.tv_sec;
 	tmp.st_mtime = stat->mtime.tv_sec;
@@ -443,6 +602,79 @@ SYSCALL_DEFINE4(fstatat64, int, dfd, const char __user *, filename,
 }
 #endif /* __ARCH_WANT_STAT64 || __ARCH_WANT_COMPAT_STAT64 */
 
+/*
+ * Set the statx results.
+ */
+static long statx_set_result(struct kstat *stat, struct statx __user *buffer)
+{
+	uid_t uid = from_kuid_munged(current_user_ns(), stat->uid);
+	gid_t gid = from_kgid_munged(current_user_ns(), stat->gid);
+
+#define __put_timestamp(kts, uts) (				\
+		__put_user(kts.tv_sec,	uts##_s		) ||	\
+		__put_user(kts.tv_nsec,	uts##_ns	))
+
+	if (__put_user(stat->result_mask,	&buffer->stx_mask	) ||
+	    __put_user(stat->mode,		&buffer->stx_mode	) ||
+	    __clear_user(&buffer->__spare0, sizeof(buffer->__spare0))	  ||
+	    __put_user(stat->nlink,		&buffer->stx_nlink	) ||
+	    __put_user(uid,			&buffer->stx_uid	) ||
+	    __put_user(gid,			&buffer->stx_gid	) ||
+	    __put_user(stat->attributes,	&buffer->stx_attributes	) ||
+	    __put_user(stat->blksize,		&buffer->stx_blksize	) ||
+	    __put_user(MAJOR(stat->rdev),	&buffer->stx_rdev_major	) ||
+	    __put_user(MINOR(stat->rdev),	&buffer->stx_rdev_minor	) ||
+	    __put_user(MAJOR(stat->dev),	&buffer->stx_dev_major	) ||
+	    __put_user(MINOR(stat->dev),	&buffer->stx_dev_minor	) ||
+	    __put_timestamp(stat->atime,	&buffer->stx_atime	) ||
+	    __put_timestamp(stat->btime,	&buffer->stx_btime	) ||
+	    __put_timestamp(stat->ctime,	&buffer->stx_ctime	) ||
+	    __put_timestamp(stat->mtime,	&buffer->stx_mtime	) ||
+	    __put_user(stat->ino,		&buffer->stx_ino	) ||
+	    __put_user(stat->size,		&buffer->stx_size	) ||
+	    __put_user(stat->blocks,		&buffer->stx_blocks	) ||
+	    __put_user(stat->version,		&buffer->stx_version	) ||
+	    __clear_user(&buffer->__spare1, sizeof(buffer->__spare1)))
+		return -EFAULT;
+
+	return 0;
+}
+
+/**
+ * sys_statx - System call to get enhanced stats
+ * @dfd: Base directory to pathwalk from *or* fd to stat.
+ * @filename: File to stat *or* NULL.
+ * @flags: AT_* flags to control pathwalk.
+ * @mask: Parts of statx struct actually required.
+ * @buffer: Result buffer.
+ *
+ * Note that if filename is NULL, then it does the equivalent of fstat() using
+ * dfd to indicate the file of interest.
+ */
+SYSCALL_DEFINE5(statx,
+		int, dfd, const char __user *, filename, unsigned, flags,
+		unsigned int, mask,
+		struct statx __user *, buffer)
+{
+	struct kstat stat;
+	int error;
+
+	if (!access_ok(VERIFY_WRITE, buffer, sizeof(*buffer)))
+		return -EFAULT;
+
+	memset(&stat, 0, sizeof(stat));
+	stat.query_flags = flags;
+	stat.request_mask = mask & STATX_ALL;
+
+	if (filename)
+		error = vfs_statx(dfd, filename, flags, &stat);
+	else
+		error = vfs_fstatx(dfd, &stat);
+	if (error)
+		return error;
+	return statx_set_result(&stat, buffer);
+}
+
 /* Caller is here responsible for sufficient locking (ie. inode->i_lock) */
 void __inode_add_bytes(struct inode *inode, loff_t bytes)
 {
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 16d2b6e874d6..f153199566b4 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -2916,8 +2916,9 @@ extern const struct inode_operations page_symlink_inode_operations;
 extern void kfree_link(void *);
 extern int generic_readlink(struct dentry *, char __user *, int);
 extern void generic_fillattr(struct inode *, struct kstat *);
-int vfs_getattr_nosec(struct path *path, struct kstat *stat);
+extern int vfs_xgetattr_nosec(struct path *path, struct kstat *stat);
 extern int vfs_getattr(struct path *, struct kstat *);
+extern int vfs_xgetattr(struct path *, struct kstat *);
 void __inode_add_bytes(struct inode *inode, loff_t bytes);
 void inode_add_bytes(struct inode *inode, loff_t bytes);
 void __inode_sub_bytes(struct inode *inode, loff_t bytes);
@@ -2935,6 +2936,8 @@ extern int vfs_lstat(const char __user *, struct kstat *);
 extern int vfs_fstat(unsigned int, struct kstat *);
 extern int vfs_fstatat(int , const char __user *, struct kstat *, int);
 extern const char *vfs_get_link(struct dentry *, struct delayed_call *);
+extern int vfs_xstat(int, const char __user *, int, struct kstat *);
+extern int vfs_xfstat(unsigned int, struct kstat *);
 
 extern int __generic_block_fiemap(struct inode *inode,
 				  struct fiemap_extent_info *fieinfo,
diff --git a/include/linux/stat.h b/include/linux/stat.h
index 075cb0c7eb2a..cf25bb5cf754 100644
--- a/include/linux/stat.h
+++ b/include/linux/stat.h
@@ -19,19 +19,26 @@
 #include <linux/uidgid.h>
 
 struct kstat {
-	u64		ino;
-	dev_t		dev;
+	u32		query_flags;	/* Operational flags */
+#define KSTAT_QUERY_FLAGS (AT_STATX_FORCE_SYNC | AT_STATX_DONT_SYNC)
+	u32		request_mask;	/* What fields the user asked for */
+	u32		result_mask;	/* What fields the user got */
 	umode_t		mode;
 	unsigned int	nlink;
+	uint32_t	blksize;	/* Preferred I/O size */
+	u64		attributes;
+	u64		ino;
+	dev_t		dev;
+	dev_t		rdev;
 	kuid_t		uid;
 	kgid_t		gid;
-	dev_t		rdev;
 	loff_t		size;
-	struct timespec  atime;
+	struct timespec	atime;
 	struct timespec	mtime;
 	struct timespec	ctime;
-	unsigned long	blksize;
-	unsigned long long	blocks;
+	struct timespec	btime;			/* File creation time */
+	u64		blocks;
+	u64		version;		/* Data version */
 };
 
 #endif
diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h
index 91a740f6b884..980c3c9b06f8 100644
--- a/include/linux/syscalls.h
+++ b/include/linux/syscalls.h
@@ -48,6 +48,7 @@ struct stat;
 struct stat64;
 struct statfs;
 struct statfs64;
+struct statx;
 struct __sysctl_args;
 struct sysinfo;
 struct timespec;
@@ -902,5 +903,7 @@ asmlinkage long sys_pkey_mprotect(unsigned long start, size_t len,
 				  unsigned long prot, int pkey);
 asmlinkage long sys_pkey_alloc(unsigned long flags, unsigned long init_val);
 asmlinkage long sys_pkey_free(int pkey);
+asmlinkage long sys_statx(int dfd, const char __user *path, unsigned flags,
+			  unsigned mask, struct statx __user *buffer);
 
 #endif
diff --git a/include/uapi/linux/fcntl.h b/include/uapi/linux/fcntl.h
index beed138bd359..c49cb6edaafa 100644
--- a/include/uapi/linux/fcntl.h
+++ b/include/uapi/linux/fcntl.h
@@ -62,6 +62,8 @@
 #define AT_SYMLINK_FOLLOW	0x400   /* Follow symbolic links.  */
 #define AT_NO_AUTOMOUNT		0x800	/* Suppress terminal automount traversal */
 #define AT_EMPTY_PATH		0x1000	/* Allow empty relative pathname */
+#define AT_STATX_FORCE_SYNC	0x2000	/* Force the attributes to be sync'd with the server */
+#define AT_STATX_DONT_SYNC	0x4000	/* Don't sync attributes with the server */
 
 
 #endif /* _UAPI_LINUX_FCNTL_H */
diff --git a/include/uapi/linux/stat.h b/include/uapi/linux/stat.h
index 7fec7e36d921..32ea14c1c960 100644
--- a/include/uapi/linux/stat.h
+++ b/include/uapi/linux/stat.h
@@ -1,6 +1,7 @@
 #ifndef _UAPI_LINUX_STAT_H
 #define _UAPI_LINUX_STAT_H
 
+#include <linux/types.h>
 
 #if defined(__KERNEL__) || !defined(__GLIBC__) || (__GLIBC__ < 2)
 
@@ -41,5 +42,128 @@
 
 #endif
 
+/*
+ * Structures for the extended file attribute retrieval system call
+ * (statx()).
+ *
+ * The caller passes a mask of what they're specifically interested in as a
+ * parameter to statx().  What statx() actually got will be indicated in
+ * st_mask upon return.
+ *
+ * For each bit in the mask argument:
+ *
+ * - if the datum is not supported:
+ *
+ *   - the bit will be cleared, and
+ *
+ *   - the datum will be set to an appropriate fabricated value if one is
+ *     available (eg. CIFS can take a default uid and gid), otherwise
+ *
+ *   - the field will be cleared;
+ *
+ * - otherwise, if explicitly requested:
+ *
+ *   - the datum will be synchronised to the server if AT_STATX_FORCE_SYNC is
+ *     set or if the datum is considered out of date, and
+ *
+ *   - the field will be filled in and the bit will be set;
+ *
+ * - otherwise, if not requested, but available in approximate form without any
+ *   effort, it will be filled in anyway, and the bit will be set upon return
+ *   (it might not be up to date, however, and no attempt will be made to
+ *   synchronise the internal state first);
+ *
+ * - otherwise the field and the bit will be cleared before returning.
+ *
+ * Items in STATX_BASIC_STATS may be marked unavailable on return, but they
+ * will have values installed for compatibility purposes so that stat() and
+ * co. can be emulated in userspace.
+ */
+struct statx {
+	/* 0x00 */
+	__u32	stx_mask;	/* What results were written [uncond] */
+	__u32	stx_blksize;	/* Preferred general I/O size [uncond] */
+	__u64	stx_attributes;	/* Flags conveying information about the file [uncond] */
+	/* 0x10 */
+	__u32	stx_nlink;	/* Number of hard links */
+	__u32	stx_uid;	/* User ID of owner */
+	__u32	stx_gid;	/* Group ID of owner */
+	__u16	stx_mode;	/* File mode */
+	__u16	__spare0[1];
+	/* 0x20 */
+	__u64	stx_ino;	/* Inode number */
+	__u64	stx_size;	/* File size */
+	__u64	stx_blocks;	/* Number of 512-byte blocks allocated */
+	__u64	stx_version;	/* Data version number */
+	/* 0x40 */
+	__s64	stx_atime_s;	/* Last access time */
+	__s64	stx_btime_s;	/* File creation time */
+	__s64	stx_ctime_s;	/* Last attribute change time */
+	__s64	stx_mtime_s;	/* Last data modification time */
+	/* 0x60 */
+	__s32	stx_atime_ns;	/* Last access time (ns part) */
+	__s32	stx_btime_ns;	/* File creation time (ns part) */
+	__s32	stx_ctime_ns;	/* Last attribute change time (ns part) */
+	__s32	stx_mtime_ns;	/* Last data modification time (ns part) */
+	/* 0x70 */
+	__u32	stx_rdev_major;	/* Device ID of special file [if bdev/cdev] */
+	__u32	stx_rdev_minor;
+	__u32	stx_dev_major;	/* ID of device containing file [uncond] */
+	__u32	stx_dev_minor;
+	/* 0x80 */
+	__u64	__spare1[16];	/* Spare space for future expansion */
+	/* 0x100 */
+};
+
+/*
+ * Flags to be stx_mask
+ *
+ * Query request/result mask for statx() and struct statx::stx_mask.
+ *
+ * These bits should be set in the mask argument of statx() to request
+ * particular items when calling statx().
+ */
+#define STATX_TYPE		0x00000001U	/* Want/got stx_mode & S_IFMT */
+#define STATX_MODE		0x00000002U	/* Want/got stx_mode & ~S_IFMT */
+#define STATX_NLINK		0x00000004U	/* Want/got stx_nlink */
+#define STATX_UID		0x00000008U	/* Want/got stx_uid */
+#define STATX_GID		0x00000010U	/* Want/got stx_gid */
+#define STATX_ATIME		0x00000020U	/* Want/got stx_atime */
+#define STATX_MTIME		0x00000040U	/* Want/got stx_mtime */
+#define STATX_CTIME		0x00000080U	/* Want/got stx_ctime */
+#define STATX_INO		0x00000100U	/* Want/got stx_ino */
+#define STATX_SIZE		0x00000200U	/* Want/got stx_size */
+#define STATX_BLOCKS		0x00000400U	/* Want/got stx_blocks */
+#define STATX_BASIC_STATS	0x000007ffU	/* The stuff in the normal stat struct */
+#define STATX_BTIME		0x00000800U	/* Want/got stx_btime */
+#define STATX_VERSION		0x00001000U	/* Want/got stx_version */
+#define STATX_ALL		0x00001fffU	/* All currently supported flags */
+
+/*
+ * Attributes to be found in stx_attributes
+ *
+ * These give information about the features or the state of a file that might
+ * be of use to ordinary userspace programs such as GUIs or ls rather than
+ * specialised tools.
+ *
+ * Note that the flags marked [I] correspond to generic FS_IOC_FLAGS
+ * semantically.  Where possible, the numerical value is picked to correspond
+ * also.
+ */
+#define STATX_ATTR_COMPRESSED		0x00000004 /* [I] File is compressed by the fs */
+#define STATX_ATTR_IMMUTABLE		0x00000010 /* [I] File is marked immutable */
+#define STATX_ATTR_APPEND		0x00000020 /* [I] File is append-only */
+#define STATX_ATTR_NODUMP		0x00000040 /* [I] File is not to be dumped */
+#define STATX_ATTR_NONUNIX_OWNERSHIP	0x00000100 /* File has non-Unix ownership details */
+#define STATX_ATTR_HAS_ACL		0x00000200 /* File has an ACL */
+#define STATX_ATTR_ENCRYPTED		0x00000800 /* [I] File requires key to decrypt in fs */
+#define STATX_ATTR_FS_IOC_FLAGS		0x00000874 /* Attrs corresponding to FS_*_FL flags */
+
+#define STATX_ATTR_KERNEL_API		0x00001000 /* File is kernel API (eg: procfs/sysfs) */
+#define STATX_ATTR_REMOTE		0x00002000 /* File is remote and needs network */
+#define STATX_ATTR_FABRICATED		0x00004000 /* File was made up by fs and is transient */
+#define STATX_ATTR_AUTOMOUNT		0x00008000 /* Dir: Automount trigger */
+#define STATX_ATTR_UNLISTED_DENTS	0x00010000 /* Dir: Lookup may find files getdents doesn't */
+
 
 #endif /* _UAPI_LINUX_STAT_H */
diff --git a/samples/Kconfig b/samples/Kconfig
index a6d2a43bbf2e..94a7488f14ae 100644
--- a/samples/Kconfig
+++ b/samples/Kconfig
@@ -105,4 +105,9 @@ config SAMPLE_BLACKFIN_GPTIMERS
 	help
 	  Build samples of blackfin gptimers sample module.
 
+config SAMPLE_STATX
+	bool "Build example extended-stat using code"
+	help
+	  Build example userspace program to use the new extended-stat syscall.
+
 endif # SAMPLES
diff --git a/samples/Makefile b/samples/Makefile
index e17d66d77f09..8eeb15e13413 100644
--- a/samples/Makefile
+++ b/samples/Makefile
@@ -2,4 +2,5 @@
 
 obj-$(CONFIG_SAMPLES)	+= kobject/ kprobes/ trace_events/ livepatch/ \
 			   hw_breakpoint/ kfifo/ kdb/ hidraw/ rpmsg/ seccomp/ \
-			   configfs/ connector/ v4l/ trace_printk/ blackfin/
+			   configfs/ connector/ v4l/ trace_printk/ blackfin/ \
+			   statx/
diff --git a/samples/statx/Makefile b/samples/statx/Makefile
new file mode 100644
index 000000000000..1f80a3d8cf45
--- /dev/null
+++ b/samples/statx/Makefile
@@ -0,0 +1,10 @@
+# kbuild trick to avoid linker error. Can be omitted if a module is built.
+obj- := dummy.o
+
+# List of programs to build
+hostprogs-$(CONFIG_SAMPLE_STATX) := test-statx
+
+# Tell kbuild to always build the programs
+always := $(hostprogs-y)
+
+HOSTCFLAGS_test-statx.o += -I$(objtree)/usr/include
diff --git a/samples/statx/test-statx.c b/samples/statx/test-statx.c
new file mode 100644
index 000000000000..2419b33fc15d
--- /dev/null
+++ b/samples/statx/test-statx.c
@@ -0,0 +1,248 @@
+/* Test the statx() system call
+ *
+ * Copyright (C) 2015 Red Hat, Inc. All Rights Reserved.
+ * Written by David Howells (dhowells@redhat.com)
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public Licence
+ * as published by the Free Software Foundation; either version
+ * 2 of the Licence, or (at your option) any later version.
+ */
+
+#define _GNU_SOURCE
+#define _ATFILE_SOURCE
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <unistd.h>
+#include <ctype.h>
+#include <errno.h>
+#include <time.h>
+#include <sys/syscall.h>
+#include <sys/types.h>
+#include <linux/stat.h>
+#include <linux/fcntl.h>
+#include <sys/stat.h>
+
+#define AT_STATX_FORCE_SYNC	0x2000
+#define AT_STATX_DONT_SYNC	0x4000
+
+static __attribute__((unused))
+ssize_t statx(int dfd, const char *filename, unsigned flags,
+	      unsigned int mask, struct statx *buffer)
+{
+	return syscall(__NR_statx, dfd, filename, flags, mask, buffer);
+}
+
+static void print_time(const char *field, __s64 tv_sec, __s32 tv_nsec)
+{
+	struct tm tm;
+	time_t tim;
+	char buffer[100];
+	int len;
+
+	tim = tv_sec;
+	if (!localtime_r(&tim, &tm)) {
+		perror("localtime_r");
+		exit(1);
+	}
+	len = strftime(buffer, 100, "%F %T", &tm);
+	if (len == 0) {
+		perror("strftime");
+		exit(1);
+	}
+	printf("%s", field);
+	fwrite(buffer, 1, len, stdout);
+	printf(".%09u", tv_nsec);
+	len = strftime(buffer, 100, "%z", &tm);
+	if (len == 0) {
+		perror("strftime2");
+		exit(1);
+	}
+	fwrite(buffer, 1, len, stdout);
+	printf("\n");
+}
+
+static void dump_statx(struct statx *stx)
+{
+	char buffer[256], ft = '?';
+
+	printf("results=%x\n", stx->stx_mask);
+
+	printf(" ");
+	if (stx->stx_mask & STATX_SIZE)
+		printf(" Size: %-15llu", (unsigned long long)stx->stx_size);
+	if (stx->stx_mask & STATX_BLOCKS)
+		printf(" Blocks: %-10llu", (unsigned long long)stx->stx_blocks);
+	printf(" IO Block: %-6llu ", (unsigned long long)stx->stx_blksize);
+	if (stx->stx_mask & STATX_MODE) {
+		switch (stx->stx_mode & S_IFMT) {
+		case S_IFIFO:	printf(" FIFO\n");			ft = 'p'; break;
+		case S_IFCHR:	printf(" character special file\n");	ft = 'c'; break;
+		case S_IFDIR:	printf(" directory\n");			ft = 'd'; break;
+		case S_IFBLK:	printf(" block special file\n");	ft = 'b'; break;
+		case S_IFREG:	printf(" regular file\n");		ft = '-'; break;
+		case S_IFLNK:	printf(" symbolic link\n");		ft = 'l'; break;
+		case S_IFSOCK:	printf(" socket\n");			ft = 's'; break;
+		default:
+			printf("unknown type (%o)\n", stx->stx_mode & S_IFMT);
+			break;
+		}
+	}
+
+	sprintf(buffer, "%02x:%02x", stx->stx_dev_major, stx->stx_dev_minor);
+	printf("Device: %-15s", buffer);
+	if (stx->stx_mask & STATX_INO)
+		printf(" Inode: %-11llu", (unsigned long long) stx->stx_ino);
+	if (stx->stx_mask & STATX_SIZE)
+		printf(" Links: %-5u", stx->stx_nlink);
+	switch (stx->stx_mask & STATX_MODE) {
+	case S_IFBLK:
+	case S_IFCHR:
+		printf(" Device type: %u,%u", stx->stx_rdev_major, stx->stx_rdev_minor);
+		break;
+	}
+	printf("\n");
+
+	if (stx->stx_mask & STATX_MODE)
+		printf("Access: (%04o/%c%c%c%c%c%c%c%c%c%c)  ",
+		       stx->stx_mode & 07777,
+		       ft,
+		       stx->stx_mode & S_IRUSR ? 'r' : '-',
+		       stx->stx_mode & S_IWUSR ? 'w' : '-',
+		       stx->stx_mode & S_IXUSR ? 'x' : '-',
+		       stx->stx_mode & S_IRGRP ? 'r' : '-',
+		       stx->stx_mode & S_IWGRP ? 'w' : '-',
+		       stx->stx_mode & S_IXGRP ? 'x' : '-',
+		       stx->stx_mode & S_IROTH ? 'r' : '-',
+		       stx->stx_mode & S_IWOTH ? 'w' : '-',
+		       stx->stx_mode & S_IXOTH ? 'x' : '-');
+	if (stx->stx_mask & STATX_UID)
+		printf("Uid: %5d   ", stx->stx_uid);
+	if (stx->stx_mask & STATX_GID)
+		printf("Gid: %5d\n", stx->stx_gid);
+
+	if (stx->stx_mask & STATX_ATIME)
+		print_time("Access: ", stx->stx_atime_s, stx->stx_atime_ns);
+	if (stx->stx_mask & STATX_MTIME)
+		print_time("Modify: ", stx->stx_mtime_s, stx->stx_mtime_ns);
+	if (stx->stx_mask & STATX_CTIME)
+		print_time("Change: ", stx->stx_ctime_s, stx->stx_ctime_ns);
+	if (stx->stx_mask & STATX_BTIME)
+		print_time(" Birth: ", stx->stx_btime_s, stx->stx_btime_ns);
+
+	if (stx->stx_mask & STATX_VERSION)
+		printf("Data version: %llxh\n",
+		       (unsigned long long)stx->stx_version);
+
+	if (stx->stx_attributes) {
+		unsigned char bits;
+		int loop, byte;
+
+		static char attr_representation[64 + 1] =
+			/* STATX_ATTR_ flags: */
+			"????????"	/* 63-56 */
+			"????????"	/* 55-48 */
+			"????????"	/* 47-40 */
+			"????????"	/* 39-32 */
+			"????????"	/* 31-24	0x00000000-ff000000 */
+			"???????u"	/* 23-16	0x00000000-00ff0000 */
+			"mfrke?AU"	/* 15- 8	0x00000000-0000ff00 */
+			"?dai?c??"	/*  7- 0	0x00000000-000000ff */
+			;
+
+		printf("Attributes: %016llx (", stx->stx_attributes);
+		for (byte = 64 - 8; byte >= 0; byte -= 8) {
+			bits = stx->stx_attributes >> byte;
+			for (loop = 7; loop >= 0; loop--) {
+				int bit = byte + loop;
+
+				if (bits & 0x80)
+					putchar(attr_representation[63 - bit]);
+				else
+					putchar('-');
+				bits <<= 1;
+			}
+			if (byte)
+				putchar(' ');
+		}
+		printf(")\n");
+	}
+
+	printf("IO-blocksize: blksize=%u\n", stx->stx_blksize);
+}
+
+static void dump_hex(unsigned long long *data, int from, int to)
+{
+	unsigned offset, print_offset = 1, col = 0;
+
+	from /= 8;
+	to = (to + 7) / 8;
+
+	for (offset = from; offset < to; offset++) {
+		if (print_offset) {
+			printf("%04x: ", offset * 8);
+			print_offset = 0;
+		}
+		printf("%016llx", data[offset]);
+		col++;
+		if ((col & 3) == 0) {
+			printf("\n");
+			print_offset = 1;
+		} else {
+			printf(" ");
+		}
+	}
+
+	if (!print_offset)
+		printf("\n");
+}
+
+int main(int argc, char **argv)
+{
+	struct statx stx;
+	int ret, raw = 0, atflag = AT_SYMLINK_NOFOLLOW;
+
+	unsigned int mask = STATX_ALL;
+
+	for (argv++; *argv; argv++) {
+		if (strcmp(*argv, "-F") == 0) {
+			atflag |= AT_STATX_FORCE_SYNC;
+			continue;
+		}
+		if (strcmp(*argv, "-D") == 0) {
+			atflag |= AT_STATX_DONT_SYNC;
+			continue;
+		}
+		if (strcmp(*argv, "-L") == 0) {
+			atflag &= ~AT_SYMLINK_NOFOLLOW;
+			continue;
+		}
+		if (strcmp(*argv, "-O") == 0) {
+			mask &= ~STATX_BASIC_STATS;
+			continue;
+		}
+		if (strcmp(*argv, "-A") == 0) {
+			atflag |= AT_NO_AUTOMOUNT;
+			continue;
+		}
+		if (strcmp(*argv, "-R") == 0) {
+			raw = 1;
+			continue;
+		}
+
+		memset(&stx, 0xbf, sizeof(stx));
+		ret = statx(AT_FDCWD, *argv, atflag, mask, &stx);
+		printf("statx(%s) = %d\n", *argv, ret);
+		if (ret < 0) {
+			perror(*argv);
+			exit(1);
+		}
+
+		if (raw)
+			dump_hex((unsigned long long *)&stx, 0, sizeof(stx));
+
+		dump_statx(&stx);
+	}
+	return 0;
+}

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [PATCH 2/4] statx: Ext4: Return enhanced file attributes
  2016-11-17 13:34 [RFC][PATCH 0/4] Enhanced file stat system call David Howells
  2016-11-17 13:35 ` [PATCH 1/4] statx: Add a system call to make enhanced file info available David Howells
@ 2016-11-17 13:35 ` David Howells
  2016-11-18  3:30   ` Andreas Dilger
  2016-11-17 13:35 ` [PATCH 3/4] statx: NFS: " David Howells
                   ` (5 subsequent siblings)
  7 siblings, 1 reply; 52+ messages in thread
From: David Howells @ 2016-11-17 13:35 UTC (permalink / raw)
  To: linux-fsdevel; +Cc: dhowells, linux-kernel

Return enhanced file attributes from the Ext4 filesystem.  This includes
the following:

 (1) The inode creation time (i_crtime) as stx_btime, setting STATX_BTIME.

 (2) The inode i_version as stx_version if a file with I_VERSION set or a
     directory, setting STATX_VERSION.

 (3) Certain FS_xxx_FL flags are copied to stx_attribute flags.


This requires that all ext4 inodes have a getattr call, not just some of
them, so to this end, split the ext4_getattr() function and only call part
of it where appropriate.

Example output:

	[root@andromeda ~]# touch foo
	[root@andromeda ~]# chattr +ai foo
	[root@andromeda ~]# /tmp/test-statx foo
	statx(foo) = 0
	results=fff
	  Size: 0               Blocks: 0          IO Block: 4096    regular file
	Device: 08:12           Inode: 2101950     Links: 1
	Access: (0644/-rw-r--r--)  Uid:     0   Gid:     0
	Access: 2016-02-11 17:08:29.031795451+0000
	Modify: 2016-02-11 17:08:29.031795451+0000
	Change: 2016-02-11 17:11:11.987790114+0000
	 Birth: 2016-02-11 17:08:29.031795451+0000
	Attributes: 0000000000000030 (-------- -------- -------- -------- -------- -------- -------- --ai----)
	IO-blocksize: blksize=4096

Signed-off-by: David Howells <dhowells@redhat.com>
---

 fs/ext4/ext4.h    |    2 ++
 fs/ext4/file.c    |    2 +-
 fs/ext4/inode.c   |   38 +++++++++++++++++++++++++++++++++++---
 fs/ext4/namei.c   |    2 ++
 fs/ext4/symlink.c |    2 ++
 5 files changed, 42 insertions(+), 4 deletions(-)

diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
index 282a51b07c57..f65e4a560c4c 100644
--- a/fs/ext4/ext4.h
+++ b/fs/ext4/ext4.h
@@ -2485,6 +2485,8 @@ extern int  ext4_getattr(struct vfsmount *mnt, struct dentry *dentry,
 				struct kstat *stat);
 extern void ext4_evict_inode(struct inode *);
 extern void ext4_clear_inode(struct inode *);
+extern int  ext4_file_getattr(struct vfsmount *mnt, struct dentry *dentry,
+			      struct kstat *stat);
 extern int  ext4_sync_inode(handle_t *, struct inode *);
 extern void ext4_dirty_inode(struct inode *, int);
 extern int ext4_change_inode_journal_flag(struct inode *, int);
diff --git a/fs/ext4/file.c b/fs/ext4/file.c
index 2a822d30e73f..20bab4b0d6fc 100644
--- a/fs/ext4/file.c
+++ b/fs/ext4/file.c
@@ -705,7 +705,7 @@ const struct file_operations ext4_file_operations = {
 
 const struct inode_operations ext4_file_inode_operations = {
 	.setattr	= ext4_setattr,
-	.getattr	= ext4_getattr,
+	.getattr	= ext4_file_getattr,
 	.listxattr	= ext4_listxattr,
 	.get_acl	= ext4_get_acl,
 	.set_acl	= ext4_set_acl,
diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index 9c064727ed62..91a49cbc4c63 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -5229,11 +5229,43 @@ int ext4_setattr(struct dentry *dentry, struct iattr *attr)
 int ext4_getattr(struct vfsmount *mnt, struct dentry *dentry,
 		 struct kstat *stat)
 {
-	struct inode *inode;
-	unsigned long long delalloc_blocks;
+	struct inode *inode = d_inode(dentry);
+	struct ext4_inode *raw_inode;
+	struct ext4_inode_info *ei = EXT4_I(inode);
+	unsigned int flags;
+
+	if (EXT4_FITS_IN_INODE(raw_inode, ei, i_crtime)) {
+		stat->result_mask |= STATX_BTIME;
+		stat->btime.tv_sec = ei->i_crtime.tv_sec;
+		stat->btime.tv_nsec = ei->i_crtime.tv_nsec;
+	}
+
+	if (S_ISDIR(inode->i_mode) || IS_I_VERSION(inode)) {
+		stat->result_mask |= STATX_VERSION;
+		stat->version = inode->i_version;
+	}
+
+	ext4_get_inode_flags(ei);
+	flags = ei->i_flags & EXT4_FL_USER_VISIBLE;
+	stat->attributes |= flags & (EXT4_IMMUTABLE_FL | EXT4_NODUMP_FL);
+	if (flags & EXT4_APPEND_FL)
+		stat->attributes |= STATX_ATTR_APPEND;
+	if (flags & EXT4_COMPR_FL)
+		stat->attributes |= STATX_ATTR_COMPRESSED;
+	if (flags & EXT4_ENCRYPT_FL)
+		stat->attributes |= STATX_ATTR_ENCRYPTED;
 
-	inode = d_inode(dentry);
 	generic_fillattr(inode, stat);
+	return 0;
+}
+
+int ext4_file_getattr(struct vfsmount *mnt, struct dentry *dentry,
+		      struct kstat *stat)
+{
+	struct inode *inode = dentry->d_inode;
+	u64 delalloc_blocks;
+
+	ext4_getattr(mnt, dentry, stat);
 
 	/*
 	 * If there is inline data in the inode, the inode will normally not
diff --git a/fs/ext4/namei.c b/fs/ext4/namei.c
index 104f8bfba718..e115281fb8c5 100644
--- a/fs/ext4/namei.c
+++ b/fs/ext4/namei.c
@@ -3882,6 +3882,7 @@ const struct inode_operations ext4_dir_inode_operations = {
 	.tmpfile	= ext4_tmpfile,
 	.rename		= ext4_rename2,
 	.setattr	= ext4_setattr,
+	.getattr	= ext4_getattr,
 	.listxattr	= ext4_listxattr,
 	.get_acl	= ext4_get_acl,
 	.set_acl	= ext4_set_acl,
@@ -3890,6 +3891,7 @@ const struct inode_operations ext4_dir_inode_operations = {
 
 const struct inode_operations ext4_special_inode_operations = {
 	.setattr	= ext4_setattr,
+	.getattr	= ext4_getattr,
 	.listxattr	= ext4_listxattr,
 	.get_acl	= ext4_get_acl,
 	.set_acl	= ext4_set_acl,
diff --git a/fs/ext4/symlink.c b/fs/ext4/symlink.c
index 557b3b0d668c..209b833633e2 100644
--- a/fs/ext4/symlink.c
+++ b/fs/ext4/symlink.c
@@ -93,6 +93,7 @@ const struct inode_operations ext4_symlink_inode_operations = {
 	.readlink	= generic_readlink,
 	.get_link	= page_get_link,
 	.setattr	= ext4_setattr,
+	.getattr	= ext4_getattr,
 	.listxattr	= ext4_listxattr,
 };
 
@@ -100,5 +101,6 @@ const struct inode_operations ext4_fast_symlink_inode_operations = {
 	.readlink	= generic_readlink,
 	.get_link	= simple_get_link,
 	.setattr	= ext4_setattr,
+	.getattr	= ext4_getattr,
 	.listxattr	= ext4_listxattr,
 };

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [PATCH 3/4] statx: NFS: Return enhanced file attributes
  2016-11-17 13:34 [RFC][PATCH 0/4] Enhanced file stat system call David Howells
  2016-11-17 13:35 ` [PATCH 1/4] statx: Add a system call to make enhanced file info available David Howells
  2016-11-17 13:35 ` [PATCH 2/4] statx: Ext4: Return enhanced file attributes David Howells
@ 2016-11-17 13:35 ` David Howells
  2016-11-17 13:35 ` [PATCH 4/4] statx: AFS: " David Howells
                   ` (4 subsequent siblings)
  7 siblings, 0 replies; 52+ messages in thread
From: David Howells @ 2016-11-17 13:35 UTC (permalink / raw)
  To: linux-fsdevel; +Cc: dhowells, linux-kernel

Return enhanced file atrributes from the NFS filesystem.  This includes the
following:

 (1) The change attribute as stx_version if NFSv4.

 (2) STATX_ATTR_AUTOMOUNT and STATX_ATTR_FABRICATED are set on referral or
     submount directories that are automounted upon.  NFS shows one
     directory with a different FSID, but the local VFS has two: the
     mountpoint directory (fabricated) and the root of the filesystem
     mounted upon it.

 (3) STATX_ATTR_REMOTE is set on files acquired over NFS.

Furthermore, what nfs_getattr() does can be controlled as follows:

 (1) If AT_STATX_DONT_SYNC is indicated then this will suppress the
     flushing of outstanding writes and the rereading of the inode's
     attributes with the server as detailed below.

 (2) Otherwise:

     (a) If AT_STATX_FORCE_SYNC is indicated, or mtime, ctime or
     	 data_version (NFSv4 only) are requested then the outstanding
     	 writes will be written to the server first.

     (b) The inode's attributes will be reread from the server:

     	 (i) if AT_STATX_FORCE_SYNC is indicated;

        (ii) if atime is requested (and atime updating is not suppressed by
     	     a mount flag); or

       (iii) if the cached attributes have expired;

If the inode isn't synchronised, then the cached attributes will be used -
even if expired - without reference to the server.

Example output:

	[root@andromeda ~]# ./samples/statx/test-statx /warthog/
	statx(/warthog/) = 0
	results=17ff
	  Size: 4096            Blocks: 8          IO Block: 1048576  directory
	Device: 00:26           Inode: 2           Links: 21
	Access: (0555/dr-xr-xr-x)  Uid:     0   Gid:     0
	Access: 2016-11-14 11:49:14.582749262+0000
	Modify: 2016-09-08 20:39:46.785788707+0100
	Change: 2016-09-08 20:39:46.785788707+0100
	Data version: 57d1be822ed62f23h
	Attributes: 0000000000002000 (-------- -------- -------- -------- -------- -------- --r----- --------)
	IO-blocksize: blksize=1048576

Note that the NFS4 protocol potentially provides a creation time that could
be passed through this interface and system, hidden and archive values that
could be passed as attributes.  There is also a backup time that could be
exposed.

Signed-off-by: David Howells <dhowells@redhat.com>
---

 fs/nfs/inode.c |   41 ++++++++++++++++++++++++++++++++++-------
 1 file changed, 34 insertions(+), 7 deletions(-)

diff --git a/fs/nfs/inode.c b/fs/nfs/inode.c
index bf4ec5ecc97e..73c4502d4abb 100644
--- a/fs/nfs/inode.c
+++ b/fs/nfs/inode.c
@@ -656,12 +656,23 @@ static bool nfs_need_revalidate_inode(struct inode *inode)
 int nfs_getattr(struct vfsmount *mnt, struct dentry *dentry, struct kstat *stat)
 {
 	struct inode *inode = d_inode(dentry);
-	int need_atime = NFS_I(inode)->cache_validity & NFS_INO_INVALID_ATIME;
+	bool force_sync = stat->query_flags & AT_STATX_FORCE_SYNC;
+	bool suppress_sync = stat->query_flags & AT_STATX_DONT_SYNC;
+	bool need_atime = NFS_I(inode)->cache_validity & NFS_INO_INVALID_ATIME;
 	int err = 0;
 
 	trace_nfs_getattr_enter(inode);
-	/* Flush out writes to the server in order to update c/mtime.  */
-	if (S_ISREG(inode->i_mode)) {
+
+	if (NFS_SERVER(inode)->nfs_client->rpc_ops->version < 4)
+		stat->request_mask &= ~STATX_VERSION;
+
+	/* Flush out writes to the server in order to update c/mtime or data
+	 * version if the user wants them.
+	 */
+	if (S_ISREG(inode->i_mode) && !suppress_sync &&
+	    (force_sync || (stat->request_mask &
+			    (STATX_MTIME | STATX_CTIME | STATX_VERSION)))
+	    ) {
 		err = filemap_write_and_wait(inode->i_mapping);
 		if (err)
 			goto out;
@@ -676,11 +687,13 @@ int nfs_getattr(struct vfsmount *mnt, struct dentry *dentry, struct kstat *stat)
 	 *  - NFS never sets MS_NOATIME or MS_NODIRATIME so there is
 	 *    no point in checking those.
 	 */
- 	if ((mnt->mnt_flags & MNT_NOATIME) ||
- 	    ((mnt->mnt_flags & MNT_NODIRATIME) && S_ISDIR(inode->i_mode)))
-		need_atime = 0;
+	if (!(stat->request_mask & STATX_ATIME) ||
+	    (mnt->mnt_flags & MNT_NOATIME) ||
+	    ((mnt->mnt_flags & MNT_NODIRATIME) && S_ISDIR(inode->i_mode)))
+		need_atime = false;
 
-	if (need_atime || nfs_need_revalidate_inode(inode)) {
+	if (!suppress_sync &&
+	    (force_sync || need_atime || nfs_need_revalidate_inode(inode))) {
 		struct nfs_server *server = NFS_SERVER(inode);
 
 		if (server->caps & NFS_CAP_READDIRPLUS)
@@ -693,6 +706,20 @@ int nfs_getattr(struct vfsmount *mnt, struct dentry *dentry, struct kstat *stat)
 		if (S_ISDIR(inode->i_mode))
 			stat->blksize = NFS_SERVER(inode)->dtsize;
 	}
+
+	generic_fillattr(inode, stat);
+	stat->ino = nfs_compat_user_ino64(NFS_FILEID(inode));
+
+	if (stat->request_mask & STATX_VERSION) {
+		stat->version = inode->i_version;
+		stat->result_mask |= STATX_VERSION;
+	}
+
+	if (IS_AUTOMOUNT(inode))
+		stat->attributes |= STATX_ATTR_FABRICATED;
+
+	stat->attributes |= STATX_ATTR_REMOTE;
+
 out:
 	trace_nfs_getattr_exit(inode, err);
 	return err;

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [PATCH 4/4] statx: AFS: Return enhanced file attributes
  2016-11-17 13:34 [RFC][PATCH 0/4] Enhanced file stat system call David Howells
                   ` (2 preceding siblings ...)
  2016-11-17 13:35 ` [PATCH 3/4] statx: NFS: " David Howells
@ 2016-11-17 13:35 ` David Howells
  2016-11-18  3:34   ` Andreas Dilger
  2016-11-18  8:47   ` David Howells
  2016-11-17 14:39 ` [RFC][PATCH 0/4] Enhanced file stat system call One Thousand Gnomes
                   ` (3 subsequent siblings)
  7 siblings, 2 replies; 52+ messages in thread
From: David Howells @ 2016-11-17 13:35 UTC (permalink / raw)
  To: linux-fsdevel; +Cc: dhowells, linux-kernel

Return enhanced file attributes from the AFS filesystem.  This includes the
following:

 (1) The data version number as st_version, setting STATX_VERSION.

 (2) STATX_ATTR_AUTOMOUNT will be set on automount directories by virtue of
     S_AUTOMOUNT being set on the inode.  These are referrals to other
     volumes or other cells.

 (3) STATX_ATTR_UNLISTED_DENTS on a directory that does cell lookup for
     non-existent names and mounts them (typically mounted on /afs with -o
     autocell).  The resulting directories are marked STATX_ATTR_FABRICATED
     as they do not actually exist in the mounted AFS directory.

 (4) Files, directories and symlinks accessed over AFS are marked
     STATX_ATTR_REMOTE.

STATX_ATIME, STATX_CTIME and STATX_BLOCKS are cleared as AFS does not
support them.

Example output:

	[root@andromeda ~]# ./samples/statx/test-statx /afs
	statx(/afs) = 0
	results=7ef
	  Size: 2048            Blocks: 0          IO Block: 4096    directory
	Device: 00:25           Inode: 1           Links: 2
	Access: (0777/drwxrwxrwx)  Uid:     0   Gid:     0
	Access: 2006-05-07 00:21:15.000000000+0100
	Modify: 2006-05-07 00:21:15.000000000+0100
	Change: 2006-05-07 00:21:15.000000000+0100
	IO-blocksize: blksize=4096

Signed-off-by: David Howells <dhowells@redhat.com>
---

 fs/afs/inode.c |   21 ++++++++++++++++-----
 1 file changed, 16 insertions(+), 5 deletions(-)

diff --git a/fs/afs/inode.c b/fs/afs/inode.c
index 86cc7264c21c..b08c405a7e1b 100644
--- a/fs/afs/inode.c
+++ b/fs/afs/inode.c
@@ -72,9 +72,9 @@ static int afs_inode_map_status(struct afs_vnode *vnode, struct key *key)
 	inode->i_uid		= vnode->status.owner;
 	inode->i_gid		= GLOBAL_ROOT_GID;
 	inode->i_size		= vnode->status.size;
-	inode->i_ctime.tv_sec	= vnode->status.mtime_server;
-	inode->i_ctime.tv_nsec	= 0;
-	inode->i_atime		= inode->i_mtime = inode->i_ctime;
+	inode->i_mtime.tv_sec	= vnode->status.mtime_server;
+	inode->i_mtime.tv_nsec	= 0;
+	inode->i_atime		= inode->i_ctime = inode->i_mtime;
 	inode->i_blocks		= 0;
 	inode->i_generation	= vnode->fid.unique;
 	inode->i_version	= vnode->status.data_version;
@@ -375,8 +375,7 @@ int afs_validate(struct afs_vnode *vnode, struct key *key)
 /*
  * read the attributes of an inode
  */
-int afs_getattr(struct vfsmount *mnt, struct dentry *dentry,
-		      struct kstat *stat)
+int afs_getattr(struct vfsmount *mnt, struct dentry *dentry, struct kstat *stat)
 {
 	struct inode *inode;
 
@@ -385,6 +384,18 @@ int afs_getattr(struct vfsmount *mnt, struct dentry *dentry,
 	_enter("{ ino=%lu v=%u }", inode->i_ino, inode->i_generation);
 
 	generic_fillattr(inode, stat);
+
+	stat->result_mask &= ~(STATX_ATIME | STATX_CTIME | STATX_BLOCKS);
+	stat->result_mask |= STATX_VERSION;
+	stat->version = inode->i_version;
+
+	if (test_bit(AFS_VNODE_AUTOCELL, &AFS_FS_I(inode)->flags))
+		stat->attributes |= STATX_ATTR_UNLISTED_DENTS;
+
+	if (test_bit(AFS_VNODE_PSEUDODIR, &AFS_FS_I(inode)->flags))
+		stat->attributes |= STATX_ATTR_FABRICATED;
+	else
+		stat->attributes |= STATX_ATTR_REMOTE;
 	return 0;
 }
 

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [RFC][PATCH 0/4] Enhanced file stat system call
  2016-11-17 13:34 [RFC][PATCH 0/4] Enhanced file stat system call David Howells
                   ` (3 preceding siblings ...)
  2016-11-17 13:35 ` [PATCH 4/4] statx: AFS: " David Howells
@ 2016-11-17 14:39 ` One Thousand Gnomes
  2016-11-17 15:10 ` Michael Kerrisk
                   ` (2 subsequent siblings)
  7 siblings, 0 replies; 52+ messages in thread
From: One Thousand Gnomes @ 2016-11-17 14:39 UTC (permalink / raw)
  To: David Howells; +Cc: linux-fsdevel, linux-kernel

>  (2) Lightweight stat (AT_STATX_DONT_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_STATX_FORCE_SYNC): Force a network fs to flush
>      buffers and go to the server, even if it thinks its cached attributes
>      are up to date.

That seems an odd way to do it. Wouldn't it be cleaner and more flexible
to give a timestamp of the oldest time you consider acceptable (and
obviously passing 0 indicates whatever you have)

>  (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.
> 
> 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.

and dfd + a name gives you fstatat() ? The cover note could be clearer on
this.

Should the fields really be split the way they are for times rather than
a struct for each one so you can write code generically to handle one of
those rather than having to have a 4 way switch statement all the time.

Another attribute that would be nice (but migt need some trivial device
layer tweaking) would be STATX_ATTR_VOLATILE for filesystems that will
probably evaporate on a reboot. That's useful information for tools like
installers and also for sanity checking things like backup paths.

Remote needs to have clear semantics: is ext4fs over nbd 'remote' for
example ?

Alan

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [RFC][PATCH 0/4] Enhanced file stat system call
  2016-11-17 13:34 [RFC][PATCH 0/4] Enhanced file stat system call David Howells
                   ` (4 preceding siblings ...)
  2016-11-17 14:39 ` [RFC][PATCH 0/4] Enhanced file stat system call One Thousand Gnomes
@ 2016-11-17 15:10 ` Michael Kerrisk
  2016-11-17 16:33 ` David Howells
  2016-11-17 16:45 ` David Howells
  7 siblings, 0 replies; 52+ messages in thread
From: Michael Kerrisk @ 2016-11-17 15:10 UTC (permalink / raw)
  To: David Howells; +Cc: Linux-Fsdevel, Linux Kernel, Linux API

Hi David,

Can you please CC linux-api@ on all future iterations of this patch!

Thanks,

Michael


On Thu, Nov 17, 2016 at 2:34 PM, David Howells <dhowells@redhat.com> wrote:
>
> Implement a new system call to provide enhanced file stats.  The patches can
> be found here:
>
>         http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=xstat
>
>
> ===========
> DESCRIPTION
> ===========
>
> The first 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 and attributes.
>      A subset of these is available through a number of filesystems (such
>      as CIFS, NFS, AFS, Ext4 and BTRFS).
>
>  (2) Lightweight stat (AT_STATX_DONT_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_STATX_FORCE_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.
>
> 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.
>
>
> =======
> TESTING
> =======
>
> A test program is added into samples/statx/ by the first patch.
>
> David
> ---
> David Howells (4):
>       statx: Add a system call to make enhanced file info available
>       statx: Ext4: Return enhanced file attributes
>       statx: NFS: Return enhanced file attributes
>       statx: AFS: Return enhanced file attributes
>
>
>  arch/x86/entry/syscalls/syscall_32.tbl |    1
>  arch/x86/entry/syscalls/syscall_64.tbl |    1
>  fs/afs/inode.c                         |   21 ++
>  fs/exportfs/expfs.c                    |    4
>  fs/ext4/ext4.h                         |    2
>  fs/ext4/file.c                         |    2
>  fs/ext4/inode.c                        |   38 ++++
>  fs/ext4/namei.c                        |    2
>  fs/ext4/symlink.c                      |    2
>  fs/nfs/inode.c                         |   41 ++++
>  fs/stat.c                              |  294 +++++++++++++++++++++++++++++---
>  include/linux/fs.h                     |    5 -
>  include/linux/stat.h                   |   19 +-
>  include/linux/syscalls.h               |    3
>  include/uapi/linux/fcntl.h             |    2
>  include/uapi/linux/stat.h              |  124 +++++++++++++
>  samples/Kconfig                        |    5 +
>  samples/Makefile                       |    3
>  samples/statx/Makefile                 |   10 +
>  samples/statx/test-statx.c             |  248 +++++++++++++++++++++++++++
>  20 files changed, 771 insertions(+), 56 deletions(-)
>  create mode 100644 samples/statx/Makefile
>  create mode 100644 samples/statx/test-statx.c
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Michael Kerrisk Linux man-pages maintainer;
http://www.kernel.org/doc/man-pages/
Author of "The Linux Programming Interface", http://blog.man7.org/

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [RFC][PATCH 0/4] Enhanced file stat system call
  2016-11-17 13:34 [RFC][PATCH 0/4] Enhanced file stat system call David Howells
                   ` (5 preceding siblings ...)
  2016-11-17 15:10 ` Michael Kerrisk
@ 2016-11-17 16:33 ` David Howells
  2016-11-17 16:45 ` David Howells
  7 siblings, 0 replies; 52+ messages in thread
From: David Howells @ 2016-11-17 16:33 UTC (permalink / raw)
  To: Michael Kerrisk; +Cc: dhowells, Linux-Fsdevel, Linux Kernel, Linux API

Michael Kerrisk <mtk.manpages@gmail.com> wrote:

> Can you please CC linux-api@ on all future iterations of this patch!

Sorry, yes - I remembered right after posting it, of course.

David

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [RFC][PATCH 0/4] Enhanced file stat system call
  2016-11-17 13:34 [RFC][PATCH 0/4] Enhanced file stat system call David Howells
                   ` (6 preceding siblings ...)
  2016-11-17 16:33 ` David Howells
@ 2016-11-17 16:45 ` David Howells
  2016-11-17 20:00   ` J. Bruce Fields
                     ` (2 more replies)
  7 siblings, 3 replies; 52+ messages in thread
From: David Howells @ 2016-11-17 16:45 UTC (permalink / raw)
  To: One Thousand Gnomes; +Cc: dhowells, linux-fsdevel, linux-kernel

One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> wrote:

> >  (2) Lightweight stat (AT_STATX_DONT_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_STATX_FORCE_SYNC): Force a network fs to flush
> >      buffers and go to the server, even if it thinks its cached attributes
> >      are up to date.
> 
> That seems an odd way to do it. Wouldn't it be cleaner and more flexible
> to give a timestamp of the oldest time you consider acceptable (and
> obviously passing 0 indicates whatever you have)

Perhaps, though adding 6-argument syscalls is apparently frowned upon.

> > 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.
> 
> and dfd + a name gives you fstatat() ?

Yes.

> The cover note could be clearer on this.

Fixed.

> Should the fields really be split the way they are for times rather than
> a struct for each one so you can write code generically to handle one of
> those rather than having to have a 4 way switch statement all the time.

It depends.  Doing so leaves 16 bytes of hole in the structure.  I could
ameliorate the wastage by using a union to overlay useful fields in the gaps,
but that's pretty icky and might be compiler dependent.

> Another attribute that would be nice (but migt need some trivial device
> layer tweaking) would be STATX_ATTR_VOLATILE for filesystems that will
> probably evaporate on a reboot. That's useful information for tools like
> installers and also for sanity checking things like backup paths.

There's a FILE_ATTRIBUTE_TEMPORARY that I could map for windows filesystems
that could be used with this.

> Remote needs to have clear semantics: is ext4fs over nbd 'remote' for
> example ?

Hmmm... Interesting question.  Probably should.  But you could be insane and
RAID an nbd and a local disk.  Further, does NFS over a loopback device to
nfsd on the same machine qualify as root?  What if that's exposing a local fs
on NBD?  Perhaps I should drop 'REMOTE' for now.  It sounds like something
that a GUI filemanager might find interesting, though.

David

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available
  2016-11-17 13:35 ` [PATCH 1/4] statx: Add a system call to make enhanced file info available David Howells
@ 2016-11-17 18:39   ` Jeff Layton
  2016-11-18  2:32     ` Andreas Dilger
  2016-11-18  8:59       ` David Howells
  2016-11-17 23:40   ` Dave Chinner
                     ` (4 subsequent siblings)
  5 siblings, 2 replies; 52+ messages in thread
From: Jeff Layton @ 2016-11-17 18:39 UTC (permalink / raw)
  To: David Howells, linux-fsdevel; +Cc: linux-kernel

On Thu, 2016-11-17 at 13:35 +0000, David Howells wrote:
> Add a system call to make extended file information available, including
> file creation, data version and some attribute flags where available
> through the underlying filesystem.
> 
> 
> ========
> OVERVIEW
> ========
> 
> The idea was initially proposed as a set of xattrs that could be retrieved
> with getxattr(), but the general preferance proved to be for a new syscall
> with an extended stat structure.
> 
> This has a number of uses:
> 
>  (1) Better support for the y2038 problem [Arnd Bergmann].
> 
>  (2) Creation time: The SMB protocol carries the creation time, which could
>      be exported by Samba, which will in turn help CIFS make use of
>      FS-Cache as that can be used for coherency data.
> 
>      This is also specified in NFSv4 as a recommended attribute and could
>      be exported by NFSD [Steve French].
> 
>  (3) Lightweight stat: Ask for just those details of interest, and allow a
>      netfs (such as NFS) to approximate anything not of interest, possibly
>      without going to the server [Trond Myklebust, Ulrich Drepper, Andreas
>      Dilger].
> 
>  (4) Heavyweight stat: Force a netfs to go to the server, even if it thinks
>      its cached attributes are up to date [Trond Myklebust].
> 
>  (5) Data version number: Could be used by userspace NFS servers [Aneesh
>      Kumar].
> 
>      Can also be used to modify fill_post_wcc() in NFSD which retrieves
>      i_version directly, but has just called vfs_getattr().  It could get
>      it from the kstat struct if it used vfs_xgetattr() instead.
> 
>  (6) BSD stat compatibility: Including more fields from the BSD stat such
>      as creation time (st_btime) and inode generation number (st_gen)
>      [Jeremy Allison, Bernd Schubert].
> 
>  (7) Inode generation number: Useful for FUSE and userspace NFS servers
>      [Bernd Schubert].  This was asked for but later deemed unnecessary
>      with the open-by-handle capability available
> 
>  (8) Extra coherency data may be useful in making backups [Andreas Dilger].
> 
>  (9) 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, so if, for instance, inode numbers or UIDs don't
>      exist or are fabricated locally...
> 
> (10) Make the fields a consistent size on all arches and make them large.
> 
> (11) Store a 16-byte volume ID in the superblock that can be returned in
>      struct xstat [Steve French].
> 
> (12) Include granularity fields in the time data to indicate the
>      granularity of each of the times (NFSv4 time_delta) [Steve French].
> 
> (13) FS_IOC_GETFLAGS value.  These could be translated to BSD's st_flags.
>      Note that the Linux IOC flags are a mess and filesystems such as Ext4
>      define flags that aren't in linux/fs.h, so translation in the kernel
>      may be a necessity (or, possibly, we provide the filesystem type too).
> 
> (14) Mask of features available on file (eg: ACLs, seclabel) [Brad Boyer,
>      Michael Kerrisk].
> 
> (15) Spare space, request flags and information flags are provided for
>      future expansion.
> 
> Note that not all of the above are implemented here.
> 
> 
> ===============
> NEW SYSTEM CALL
> ===============
> 
> The new system call is:
> 
> 	int ret = statx(int dfd,
> 			const char *filename,
> 			unsigned int flags,
> 			unsigned int mask,
> 			struct statx *buffer);
> 
> The dfd, filename and flags parameters indicate the file to query.  There
> is no equivalent of lstat() as that can be emulated with statx() by passing
> AT_SYMLINK_NOFOLLOW in flags.  There is also no equivalent of fstat() as
> that can be emulated by passing a NULL filename to statx() with the fd of
> interest in dfd.
> 
> AT_STATX_FORCE_SYNC can be set in flags.  This will require a network
> filesystem to synchronise its attributes with the server.
> 
> AT_STATX_DONT_SYNC can be set in flags.  This will suppress synchronisation
> with the server in a network filesystem.  The resulting values should be
> considered approximate.
> 
> If neither AT_STATX_*_SYNC flag is set, the behaviour is the default for
> stat() on that filesystem.
> 

We also need to specify here what happens if both bits are set. Should
that be -EINVAL?



> mask is a bitmask indicating the fields in struct statx that are of
> interest to the caller.  The user should set this to STATX_BASIC_STATS to
> get the basic set returned by stat().  It should be note that asking for
> more information may entail more I/O operations.
> 
> buffer points to the destination for the data.  This must be 256 bytes in
> size.
> 
> 
> ======================
> MAIN ATTRIBUTES RECORD
> ======================
> 
> The following structures are defined in which to return the main attribute
> set:
> 
> 	struct statx {
> 		__u32	stx_mask;
> 		__u32	stx_blksize;
> 		__u64	stx_attributes;
> 		__u32	stx_nlink;
> 		__u32	stx_uid;
> 		__u32	stx_gid;
> 		__u16	stx_mode;
> 		__u16	__spare0[1];
> 		__u64	stx_ino;
> 		__u64	stx_size;
> 		__u64	stx_blocks;
> 		__u64	stx_version;
> 		__s64	stx_atime;
> 		__s64	stx_btime;
> 		__s64	stx_ctime;
> 		__s64	stx_mtime;
> 		__s32	stx_atime_ns;
> 		__s32	stx_btime_ns;
> 		__s32	stx_ctime_ns;
> 		__s32	stx_mtime_ns;
> 		__u32	stx_rdev_major;
> 		__u32	stx_rdev_minor;
> 		__u32	stx_dev_major;
> 		__u32	stx_dev_minor;
> 		__u64	__spare1[16];
> 	};
> 
> The defined bits in request_mask and stx_mask are:
> 
> 	STATX_TYPE		Want/got stx_mode & S_IFMT
> 	STATX_MODE		Want/got stx_mode & ~S_IFMT
> 	STATX_NLINK		Want/got stx_nlink
> 	STATX_UID		Want/got stx_uid
> 	STATX_GID		Want/got stx_gid
> 	STATX_ATIME		Want/got stx_atime{,_ns}
> 	STATX_MTIME		Want/got stx_mtime{,_ns}
> 	STATX_CTIME		Want/got stx_ctime{,_ns}
> 	STATX_INO		Want/got stx_ino
> 	STATX_SIZE		Want/got stx_size
> 	STATX_BLOCKS		Want/got stx_blocks
> 	STATX_BASIC_STATS	[The stuff in the normal stat struct]
> 	STATX_BTIME		Want/got stx_btime{,_ns}
> 	STATX_VERSION		Want/got stx_version
> 	STATX_ALL		[All currently available stuff]
> 
> stx_btime is the file creation time; stx_version is the data version number
> (i_version); stx_mask is a bitmask indicating the data provided; and
> __spares*[] are where as-yet undefined fields can be placed.
> 
> Time fields are split into separate seconds and nanoseconds fields to make
> packing easier and the granularities can be queried with the filesystem
> info system call.  Note that times will be negative if before 1970; in such
> a case, the nanosecond fields will also be negative if not zero.
> 
> The bits defined in the stx_attributes field convey information about a
> file, how it is accessed, where it is and what it does.  The following
> attributes map to FS_*_FL flags and are the same numerical value:
> 
> 	STATX_ATTR_COMPRESSED		File is compressed by the fs
> 	STATX_ATTR_IMMUTABLE		File is marked immutable
> 	STATX_ATTR_APPEND		File is append-only
> 	STATX_ATTR_NODUMP		File is not to be dumped
> 	STATX_ATTR_ENCRYPTED		File requires key to decrypt in fs
> 
> The supported flags are listed by:
> 
> 	STATX_ATTR_FS_IOC_FLAGS
> 
> [Are any other IOC flags of sufficient general interest to be exposed
> through this interface?]
> 
> New flags include:
> 
> 	STATX_ATTR_NONUNIX_OWNERSHIP	File doesn't have Unixy ownership
> 	STATX_ATTR_HAS_ACL		File has an ACL
> 	STATX_ATTR_KERNEL_API		File is kernel API (eg: procfs/sysfs)
> 	STATX_ATTR_REMOTE		File is remote and needs network
> 	STATX_ATTR_FABRICATED		File was made up by fs
> 	STATX_ATTR_AUTOMOUNT		Object is an automount trigger
> 	STATX_ATTR_UNLISTED_DENTS	Dir: Lookup may find files getdents doesn't
> 
> These are for the use of GUI tools that might want to mark files specially,
> depending on what they are.
> 
> Fields in struct statx come in a number of classes:
> 
>  (0) stx_dev_*, stx_blksize.
> 
>      These are local system information and are always available.
> 
>  (1) stx_mode, stx_nlinks, stx_uid, stx_gid, stx_[amc]time*, stx_ino,
>      stx_size, stx_blocks.
> 
>      These will be returned whether the caller asks for them or not.  The
>      corresponding bits in stx_mask will be set to indicate whether they
>      actually have valid values.
> 
>      If the caller didn't ask for them, then they may be approximated.  For
>      example, NFS won't waste any time updating them from the server,
>      unless as a byproduct of updating something requested.
> 
>      If the values don't actually exist for the underlying object (such as
>      UID or GID on a DOS file), then the bit won't be set in the stx_mask,
>      even if the caller asked for the value.  In such a case, the returned
>      value will be a fabrication.
> 
>      Note that there are instances where the type might not be valid, for
>      instance Windows reparse points.
> 
>  (2) stx_rdev_*.
> 
>      This will be set only if stx_mode indicates we're looking at a
>      blockdev or a chardev, otherwise will be 0.
> 
>  (3) stx_btime*, stx_version.
> 
>      Similar to (1), except these will be set to 0 if they don't exist.
> 
> 
> =======
> TESTING
> =======
> 
> The following test program can be used to test the statx system call:
> 
> 	samples/statx/test-statx.c
> 
> Just compile and run, passing it paths to the files you want to examine.
> The file is built automatically if CONFIG_SAMPLES is enabled.
> 
> Here's some example output.  Firstly, an NFS directory that crosses to
> another FSID.  Note that the FABRICATED and AUTOMOUNT info flags are set.
> The former because the directory is invented locally as we don't see the
> underlying dir on the server, the latter because transiting this directory
> will cause d_automount to be invoked by the VFS.
> 
> 	[root@andromeda tmp]# ./samples/statx/test-statx -A /warthog/data
> 	statx(/warthog/data) = 0
> 	results=17ff
> 	  Size: 4096            Blocks: 8          IO Block: 1048576  directory
> 	Device: 00:26           Inode: 1703937     Links: 124
> 	Access: (3777/drwxrwxrwx)  Uid:     0   Gid:  4041
> 	Access: 2016-11-10 15:52:11.219935864+0000
> 	Modify: 2016-11-10 08:07:32.482314928+0000
> 	Change: 2016-11-10 08:07:32.482314928+0000
> 	Data version: 58242ac41cbf8ab0h
> 	Attributes: 000000000000e000 (-------- -------- -------- -------- -------- -------- mfr----- --------)
> 	IO-blocksize: blksize=1048576
> 
> Secondly, the result of automounting on that directory.
> 
> 	[root@andromeda tmp]# ./samples/statx/test-statx /warthog/data
> 	statx(/warthog/data) = 0
> 	results=17ff
> 	  Size: 4096            Blocks: 8          IO Block: 1048576  directory
> 	Device: 00:27           Inode: 2           Links: 124
> 	Access: (3777/drwxrwxrwx)  Uid:     0   Gid:  4041
> 	Access: 2016-11-10 15:52:11.219935864+0000
> 	Modify: 2016-11-10 08:07:32.482314928+0000
> 	Change: 2016-11-10 08:07:32.482314928+0000
> 	Data version: 58242ac41cbf8ab0h
> 	Attributes: 0000000000002000 (-------- -------- -------- -------- -------- -------- --r----- --------)
> 	IO-blocksize: blksize=1048576
> 
> Signed-off-by: David Howells <dhowells@redhat.com>
> ---
> 
>  arch/x86/entry/syscalls/syscall_32.tbl |    1 
>  arch/x86/entry/syscalls/syscall_64.tbl |    1 
>  fs/exportfs/expfs.c                    |    4 
>  fs/stat.c                              |  294 +++++++++++++++++++++++++++++---
>  include/linux/fs.h                     |    5 -
>  include/linux/stat.h                   |   19 +-
>  include/linux/syscalls.h               |    3 
>  include/uapi/linux/fcntl.h             |    2 
>  include/uapi/linux/stat.h              |  124 +++++++++++++
>  samples/Kconfig                        |    5 +
>  samples/Makefile                       |    3 
>  samples/statx/Makefile                 |   10 +
>  samples/statx/test-statx.c             |  248 +++++++++++++++++++++++++++
>  13 files changed, 679 insertions(+), 40 deletions(-)
>  create mode 100644 samples/statx/Makefile
>  create mode 100644 samples/statx/test-statx.c
> 
> diff --git a/arch/x86/entry/syscalls/syscall_32.tbl b/arch/x86/entry/syscalls/syscall_32.tbl
> index 2b3618542544..9ba050fe47f3 100644
> --- a/arch/x86/entry/syscalls/syscall_32.tbl
> +++ b/arch/x86/entry/syscalls/syscall_32.tbl
> @@ -389,3 +389,4 @@
>  380	i386	pkey_mprotect		sys_pkey_mprotect
>  381	i386	pkey_alloc		sys_pkey_alloc
>  382	i386	pkey_free		sys_pkey_free
> +383	i386	statx			sys_statx
> diff --git a/arch/x86/entry/syscalls/syscall_64.tbl b/arch/x86/entry/syscalls/syscall_64.tbl
> index e93ef0b38db8..5aef183e2f85 100644
> --- a/arch/x86/entry/syscalls/syscall_64.tbl
> +++ b/arch/x86/entry/syscalls/syscall_64.tbl
> @@ -338,6 +338,7 @@
>  329	common	pkey_mprotect		sys_pkey_mprotect
>  330	common	pkey_alloc		sys_pkey_alloc
>  331	common	pkey_free		sys_pkey_free
> +332	common	statx			sys_statx
>  
>  #
>  # x32-specific system call numbers start at 512 to avoid cache impact
> diff --git a/fs/exportfs/expfs.c b/fs/exportfs/expfs.c
> index a4b531be9168..2acc31751248 100644
> --- a/fs/exportfs/expfs.c
> +++ b/fs/exportfs/expfs.c
> @@ -299,7 +299,9 @@ static int get_name(const struct path *path, char *name, struct dentry *child)
>  	 * filesystem supports 64-bit inode numbers.  So we need to
>  	 * actually call ->getattr, not just read i_ino:
>  	 */
> -	error = vfs_getattr_nosec(&child_path, &stat);
> +	stat.query_flags = 0;
> +	stat.request_mask = STATX_BASIC_STATS;
> +	error = vfs_xgetattr_nosec(&child_path, &stat);
>  	if (error)
>  		return error;
>  	buffer.ino = stat.ino;
> diff --git a/fs/stat.c b/fs/stat.c
> index bc045c7994e1..78c0a5086038 100644
> --- a/fs/stat.c
> +++ b/fs/stat.c
> @@ -18,6 +18,15 @@
>  #include <asm/uaccess.h>
>  #include <asm/unistd.h>
>  
> +/**
> + * generic_fillattr - Fill in the basic attributes from the inode struct
> + * @inode: Inode to use as the source
> + * @stat: Where to fill in the attributes
> + *
> + * Fill in the basic attributes in the kstat structure from data that's to be
> + * found on the VFS inode structure.  This is the default if no getattr inode
> + * operation is supplied.
> + */
>  void generic_fillattr(struct inode *inode, struct kstat *stat)
>  {
>  	stat->dev = inode->i_sb->s_dev;
> @@ -27,87 +36,189 @@ void generic_fillattr(struct inode *inode, struct kstat *stat)
>  	stat->uid = inode->i_uid;
>  	stat->gid = inode->i_gid;
>  	stat->rdev = inode->i_rdev;
> -	stat->size = i_size_read(inode);
> -	stat->atime = inode->i_atime;
>  	stat->mtime = inode->i_mtime;
>  	stat->ctime = inode->i_ctime;
> -	stat->blksize = (1 << inode->i_blkbits);
> +	stat->size = i_size_read(inode);
>  	stat->blocks = inode->i_blocks;
> -}
> +	stat->blksize = 1 << inode->i_blkbits;
>  
> +	stat->result_mask |= STATX_BASIC_STATS;
> +	if (IS_NOATIME(inode))
> +		stat->result_mask &= ~STATX_ATIME;
> +	else
> +		stat->atime = inode->i_atime;
> +
> +	if (IS_AUTOMOUNT(inode))
> +		stat->attributes |= STATX_ATTR_AUTOMOUNT;
> +}
>  EXPORT_SYMBOL(generic_fillattr);
>  
>  /**
> - * vfs_getattr_nosec - getattr without security checks
> + * vfs_xgetattr_nosec - getattr without security checks
>   * @path: file to get attributes from
>   * @stat: structure to return attributes in
>   *
>   * Get attributes without calling security_inode_getattr.
>   *
> - * Currently the only caller other than vfs_getattr is internal to the
> - * filehandle lookup code, which uses only the inode number and returns
> - * no attributes to any user.  Any other code probably wants
> - * vfs_getattr.
> + * Currently the only caller other than vfs_xgetattr is internal to the
> + * filehandle lookup code, which uses only the inode number and returns no
> + * attributes to any user.  Any other code probably wants vfs_xgetattr.
> + *
> + * The caller must set stat->request_mask to indicate what they want and
> + * stat->query_flags to indicate whether the server should be queried.
>   */
> -int vfs_getattr_nosec(struct path *path, struct kstat *stat)
> +int vfs_xgetattr_nosec(struct path *path, struct kstat *stat)
>  {
>  	struct inode *inode = d_backing_inode(path->dentry);
>  
> +	stat->query_flags &= ~KSTAT_QUERY_FLAGS;
> +
> +	stat->result_mask = 0;
> +	stat->attributes = 0;
>  	if (inode->i_op->getattr)
>  		return inode->i_op->getattr(path->mnt, path->dentry, stat);
>  
>  	generic_fillattr(inode, stat);
>  	return 0;
>  }
> +EXPORT_SYMBOL(vfs_xgetattr_nosec);
>  
> -EXPORT_SYMBOL(vfs_getattr_nosec);
> -
> -int vfs_getattr(struct path *path, struct kstat *stat)
> +/*
> + * vfs_xgetattr - Get the enhanced basic attributes of a file
> + * @path: The file of interest
> + * @stat: Where to return the statistics
> + *
> + * Ask the filesystem for a file's attributes.  The caller must have preset
> + * stat->request_mask and stat->query_flags to indicate what they want.
> + *
> + * If the file is remote, the filesystem can be forced to update the attributes
> + * from the backing store by passing AT_FORCE_ATTR_SYNC in query_flags or can
> + * suppress the update by passing AT_NO_ATTR_SYNC.
> + *
> + * Bits must have been set in stat->request_mask to indicate which attributes
> + * the caller wants retrieving.  Any such attribute not requested may be
> + * returned anyway, but the value may be approximate, and, if remote, may not
> + * have been synchronised with the server.
> + *
> + * 0 will be returned on success, and a -ve error code if unsuccessful.
> + */
> +int vfs_xgetattr(struct path *path, struct kstat *stat)
>  {
>  	int retval;
>  
>  	retval = security_inode_getattr(path);
>  	if (retval)
>  		return retval;
> -	return vfs_getattr_nosec(path, stat);
> +	return vfs_xgetattr_nosec(path, stat);
>  }
> +EXPORT_SYMBOL(vfs_xgetattr);
>  
> +/**
> + * vfs_getattr - Get the basic attributes of a file
> + * @path: The file of interest
> + * @stat: Where to return the statistics
> + *
> + * Ask the filesystem for a file's attributes.  If remote, the filesystem isn't
> + * forced to update its files from the backing store.  Only the basic set of
> + * attributes will be retrieved; anyone wanting more must use vfs_xgetattr(),
> + * as must anyone who wants to force attributes to be sync'd with the server.
> + *
> + * 0 will be returned on success, and a -ve error code if unsuccessful.
> + */
> +int vfs_getattr(struct path *path, struct kstat *stat)
> +{
> +	stat->query_flags = 0;
> +	stat->request_mask = STATX_BASIC_STATS;
> +	return vfs_xgetattr(path, stat);
> +}
>  EXPORT_SYMBOL(vfs_getattr);
>  
> -int vfs_fstat(unsigned int fd, struct kstat *stat)
> +/**
> + * vfs_fstatx - Get the enhanced basic attributes by file descriptor
> + * @fd: The file descriptor referring to the file of interest
> + * @stat: The result structure to fill in.
> + *
> + * This function is a wrapper around vfs_xgetattr().  The main difference is
> + * that it uses a file descriptor to determine the file location.
> + *
> + * The caller must have preset stat->query_flags and stat->request_mask as for
> + * vfs_xgetattr().
> + *
> + * 0 will be returned on success, and a -ve error code if unsuccessful.
> + */
> +int vfs_fstatx(unsigned int fd, struct kstat *stat)
>  {
>  	struct fd f = fdget_raw(fd);
>  	int error = -EBADF;
>  
>  	if (f.file) {
> -		error = vfs_getattr(&f.file->f_path, stat);
> +		error = vfs_xgetattr(&f.file->f_path, stat);
>  		fdput(f);
>  	}
>  	return error;
>  }
> +EXPORT_SYMBOL(vfs_fstatx);
> +
> +/**
> + * vfs_fstat - Get basic attributes by file descriptor
> + * @fd: The file descriptor referring to the file of interest
> + * @stat: The result structure to fill in.
> + *
> + * This function is a wrapper around vfs_getattr().  The main difference is
> + * that it uses a file descriptor to determine the file location.
> + *
> + * 0 will be returned on success, and a -ve error code if unsuccessful.
> + */
> +int vfs_fstat(unsigned int fd, struct kstat *stat)
> +{
> +	stat->query_flags = 0;
> +	stat->request_mask = STATX_BASIC_STATS;
> +	return vfs_fstatx(fd, stat);
> +}
>  EXPORT_SYMBOL(vfs_fstat);
>  
> -int vfs_fstatat(int dfd, const char __user *filename, struct kstat *stat,
> -		int flag)
> +/**
> + * vfs_statx - Get basic and extra attributes by filename
> + * @dfd: A file descriptor representing the base dir for a relative filename
> + * @filename: The name of the file of interest
> + * @flags: Flags to control the query
> + * @stat: The result structure to fill in.
> + *
> + * This function is a wrapper around vfs_xgetattr().  The main difference is
> + * that it uses a filename and base directory to determine the file location.
> + * Additionally, the addition of AT_SYMLINK_NOFOLLOW to flags will prevent a
> + * symlink at the given name from being referenced.
> + *
> + * The caller must have preset stat->request_mask as for vfs_xgetattr().  The
> + * flags are also used to load up stat->query_flags.
> + *
> + * 0 will be returned on success, and a -ve error code if unsuccessful.
> + */
> +int vfs_statx(int dfd, const char __user *filename, int flags,
> +	      struct kstat *stat)
>  {
>  	struct path path;
>  	int error = -EINVAL;
> -	unsigned int lookup_flags = 0;
> +	unsigned int lookup_flags = LOOKUP_FOLLOW | LOOKUP_AUTOMOUNT;
>  
> -	if ((flag & ~(AT_SYMLINK_NOFOLLOW | AT_NO_AUTOMOUNT |
> -		      AT_EMPTY_PATH)) != 0)
> -		goto out;
> +	if ((flags & ~(AT_SYMLINK_NOFOLLOW | AT_NO_AUTOMOUNT |
> +		       AT_EMPTY_PATH | KSTAT_QUERY_FLAGS)) != 0)
> +		return -EINVAL;
>  
> -	if (!(flag & AT_SYMLINK_NOFOLLOW))
> -		lookup_flags |= LOOKUP_FOLLOW;
> -	if (flag & AT_EMPTY_PATH)
> +	if (flags & AT_SYMLINK_NOFOLLOW)
> +		lookup_flags &= ~LOOKUP_FOLLOW;
> +	if (flags & AT_NO_AUTOMOUNT)
> +		lookup_flags &= ~LOOKUP_AUTOMOUNT;
> +	if (flags & AT_EMPTY_PATH)
>  		lookup_flags |= LOOKUP_EMPTY;
> +	stat->query_flags = flags;
> +
>  retry:
>  	error = user_path_at(dfd, filename, lookup_flags, &path);
>  	if (error)
>  		goto out;
>  
> -	error = vfs_getattr(&path, stat);
> +	error = vfs_xgetattr(&path, stat);
>  	path_put(&path);
>  	if (retry_estale(error, lookup_flags)) {
>  		lookup_flags |= LOOKUP_REVAL;
> @@ -116,17 +227,65 @@ int vfs_fstatat(int dfd, const char __user *filename, struct kstat *stat,
>  out:
>  	return error;
>  }
> +EXPORT_SYMBOL(vfs_statx);
> +
> +/**
> + * vfs_fstatat - Get basic attributes by filename
> + * @dfd: A file descriptor representing the base dir for a relative filename
> + * @filename: The name of the file of interest
> + * @flags: Flags to control the query
> + * @stat: The result structure to fill in.
> + *
> + * This function is a wrapper around vfs_statx().  The difference is that it
> + * preselects basic stats only.  The flags are used to load up
> + * stat->query_flags in addition to indicating symlink handling during path
> + * resolution.
> + *
> + * 0 will be returned on success, and a -ve error code if unsuccessful.
> + */
> +int vfs_fstatat(int dfd, const char __user *filename, struct kstat *stat,
> +		int flags)
> +{
> +	stat->request_mask = STATX_BASIC_STATS;
> +	return vfs_statx(dfd, filename, flags, stat);
> +}
>  EXPORT_SYMBOL(vfs_fstatat);
>  
> -int vfs_stat(const char __user *name, struct kstat *stat)
> +/**
> + * vfs_stat - Get basic attributes by filename
> + * @filename: The name of the file of interest
> + * @stat: The result structure to fill in.
> + *
> + * This function is a wrapper around vfs_statx().  The difference is that it
> + * preselects basic stats only, terminal symlinks are followed regardless and a
> + * remote filesystem can't be forced to query the server.  If such is desired,
> + * vfs_statx() should be used instead.
> + *
> + * 0 will be returned on success, and a -ve error code if unsuccessful.
> + */
> +int vfs_stat(const char __user *filename, struct kstat *stat)
>  {
> -	return vfs_fstatat(AT_FDCWD, name, stat, 0);
> +	stat->request_mask = STATX_BASIC_STATS;
> +	return vfs_statx(AT_FDCWD, filename, 0, stat);
>  }
>  EXPORT_SYMBOL(vfs_stat);
>  
> +/**
> + * vfs_lstat - Get basic attrs by filename, without following terminal symlink
> + * @filename: The name of the file of interest
> + * @stat: The result structure to fill in.
> + *
> + * This function is a wrapper around vfs_statx().  The difference is that it
> + * preselects basic stats only, terminal symlinks are note followed regardless
> + * and a remote filesystem can't be forced to query the server.  If such is
> + * desired, vfs_statx() should be used instead.
> + *
> + * 0 will be returned on success, and a -ve error code if unsuccessful.
> + */
>  int vfs_lstat(const char __user *name, struct kstat *stat)
>  {
> -	return vfs_fstatat(AT_FDCWD, name, stat, AT_SYMLINK_NOFOLLOW);
> +	stat->request_mask = STATX_BASIC_STATS;
> +	return vfs_statx(AT_FDCWD, name, AT_SYMLINK_NOFOLLOW, stat);
>  }
>  EXPORT_SYMBOL(vfs_lstat);
>  
> @@ -141,7 +300,7 @@ static int cp_old_stat(struct kstat *stat, struct __old_kernel_stat __user * sta
>  {
>  	static int warncount = 5;
>  	struct __old_kernel_stat tmp;
> -	
> +
>  	if (warncount > 0) {
>  		warncount--;
>  		printk(KERN_WARNING "VFS: Warning: %s using old stat() call. Recompile your binary.\n",
> @@ -166,7 +325,7 @@ static int cp_old_stat(struct kstat *stat, struct __old_kernel_stat __user * sta
>  #if BITS_PER_LONG == 32
>  	if (stat->size > MAX_NON_LFS)
>  		return -EOVERFLOW;
> -#endif	
> +#endif
>  	tmp.st_size = stat->size;
>  	tmp.st_atime = stat->atime.tv_sec;
>  	tmp.st_mtime = stat->mtime.tv_sec;
> @@ -443,6 +602,79 @@ SYSCALL_DEFINE4(fstatat64, int, dfd, const char __user *, filename,
>  }
>  #endif /* __ARCH_WANT_STAT64 || __ARCH_WANT_COMPAT_STAT64 */
>  
> +/*
> + * Set the statx results.
> + */
> +static long statx_set_result(struct kstat *stat, struct statx __user *buffer)
> +{
> +	uid_t uid = from_kuid_munged(current_user_ns(), stat->uid);
> +	gid_t gid = from_kgid_munged(current_user_ns(), stat->gid);
> +
> +#define __put_timestamp(kts, uts) (				\
> +		__put_user(kts.tv_sec,	uts##_s		) ||	\
> +		__put_user(kts.tv_nsec,	uts##_ns	))
> +
> +	if (__put_user(stat->result_mask,	&buffer->stx_mask	) ||
> +	    __put_user(stat->mode,		&buffer->stx_mode	) ||
> +	    __clear_user(&buffer->__spare0, sizeof(buffer->__spare0))	  ||
> +	    __put_user(stat->nlink,		&buffer->stx_nlink	) ||
> +	    __put_user(uid,			&buffer->stx_uid	) ||
> +	    __put_user(gid,			&buffer->stx_gid	) ||
> +	    __put_user(stat->attributes,	&buffer->stx_attributes	) ||
> +	    __put_user(stat->blksize,		&buffer->stx_blksize	) ||
> +	    __put_user(MAJOR(stat->rdev),	&buffer->stx_rdev_major	) ||
> +	    __put_user(MINOR(stat->rdev),	&buffer->stx_rdev_minor	) ||
> +	    __put_user(MAJOR(stat->dev),	&buffer->stx_dev_major	) ||
> +	    __put_user(MINOR(stat->dev),	&buffer->stx_dev_minor	) ||
> +	    __put_timestamp(stat->atime,	&buffer->stx_atime	) ||
> +	    __put_timestamp(stat->btime,	&buffer->stx_btime	) ||
> +	    __put_timestamp(stat->ctime,	&buffer->stx_ctime	) ||
> +	    __put_timestamp(stat->mtime,	&buffer->stx_mtime	) ||
> +	    __put_user(stat->ino,		&buffer->stx_ino	) ||
> +	    __put_user(stat->size,		&buffer->stx_size	) ||
> +	    __put_user(stat->blocks,		&buffer->stx_blocks	) ||
> +	    __put_user(stat->version,		&buffer->stx_version	) ||
> +	    __clear_user(&buffer->__spare1, sizeof(buffer->__spare1)))
> +		return -EFAULT;
> +
> +	return 0;
> +}
> +
> +/**
> + * sys_statx - System call to get enhanced stats
> + * @dfd: Base directory to pathwalk from *or* fd to stat.
> + * @filename: File to stat *or* NULL.
> + * @flags: AT_* flags to control pathwalk.
> + * @mask: Parts of statx struct actually required.
> + * @buffer: Result buffer.
> + *
> + * Note that if filename is NULL, then it does the equivalent of fstat() using
> + * dfd to indicate the file of interest.
> + */
> +SYSCALL_DEFINE5(statx,
> +		int, dfd, const char __user *, filename, unsigned, flags,
> +		unsigned int, mask,
> +		struct statx __user *, buffer)
> +{
> +	struct kstat stat;
> +	int error;
> +
> +	if (!access_ok(VERIFY_WRITE, buffer, sizeof(*buffer)))
> +		return -EFAULT;
> +
> +	memset(&stat, 0, sizeof(stat));
> +	stat.query_flags = flags;
> +	stat.request_mask = mask & STATX_ALL;
> +
> +	if (filename)
> +		error = vfs_statx(dfd, filename, flags, &stat);
> +	else
> +		error = vfs_fstatx(dfd, &stat);
> +	if (error)
> +		return error;
> +	return statx_set_result(&stat, buffer);
> +}
> +
>  /* Caller is here responsible for sufficient locking (ie. inode->i_lock) */
>  void __inode_add_bytes(struct inode *inode, loff_t bytes)
>  {
> diff --git a/include/linux/fs.h b/include/linux/fs.h
> index 16d2b6e874d6..f153199566b4 100644
> --- a/include/linux/fs.h
> +++ b/include/linux/fs.h
> @@ -2916,8 +2916,9 @@ extern const struct inode_operations page_symlink_inode_operations;
>  extern void kfree_link(void *);
>  extern int generic_readlink(struct dentry *, char __user *, int);
>  extern void generic_fillattr(struct inode *, struct kstat *);
> -int vfs_getattr_nosec(struct path *path, struct kstat *stat);
> +extern int vfs_xgetattr_nosec(struct path *path, struct kstat *stat);
>  extern int vfs_getattr(struct path *, struct kstat *);
> +extern int vfs_xgetattr(struct path *, struct kstat *);
>  void __inode_add_bytes(struct inode *inode, loff_t bytes);
>  void inode_add_bytes(struct inode *inode, loff_t bytes);
>  void __inode_sub_bytes(struct inode *inode, loff_t bytes);
> @@ -2935,6 +2936,8 @@ extern int vfs_lstat(const char __user *, struct kstat *);
>  extern int vfs_fstat(unsigned int, struct kstat *);
>  extern int vfs_fstatat(int , const char __user *, struct kstat *, int);
>  extern const char *vfs_get_link(struct dentry *, struct delayed_call *);
> +extern int vfs_xstat(int, const char __user *, int, struct kstat *);
> +extern int vfs_xfstat(unsigned int, struct kstat *);
>  
>  extern int __generic_block_fiemap(struct inode *inode,
>  				  struct fiemap_extent_info *fieinfo,
> diff --git a/include/linux/stat.h b/include/linux/stat.h
> index 075cb0c7eb2a..cf25bb5cf754 100644
> --- a/include/linux/stat.h
> +++ b/include/linux/stat.h
> @@ -19,19 +19,26 @@
>  #include <linux/uidgid.h>
>  
>  struct kstat {
> -	u64		ino;
> -	dev_t		dev;
> +	u32		query_flags;	/* Operational flags */
> +#define KSTAT_QUERY_FLAGS (AT_STATX_FORCE_SYNC | AT_STATX_DONT_SYNC)
> +	u32		request_mask;	/* What fields the user asked for */
> +	u32		result_mask;	/* What fields the user got */
>  	umode_t		mode;
>  	unsigned int	nlink;
> +	uint32_t	blksize;	/* Preferred I/O size */
> +	u64		attributes;
> +	u64		ino;
> +	dev_t		dev;
> +	dev_t		rdev;
>  	kuid_t		uid;
>  	kgid_t		gid;
> -	dev_t		rdev;
>  	loff_t		size;
> -	struct timespec  atime;
> +	struct timespec	atime;
>  	struct timespec	mtime;
>  	struct timespec	ctime;
> -	unsigned long	blksize;
> -	unsigned long long	blocks;
> +	struct timespec	btime;			/* File creation time */
> +	u64		blocks;
> +	u64		version;		/* Data version */
>  };
>  
>  #endif
> diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h
> index 91a740f6b884..980c3c9b06f8 100644
> --- a/include/linux/syscalls.h
> +++ b/include/linux/syscalls.h
> @@ -48,6 +48,7 @@ struct stat;
>  struct stat64;
>  struct statfs;
>  struct statfs64;
> +struct statx;
>  struct __sysctl_args;
>  struct sysinfo;
>  struct timespec;
> @@ -902,5 +903,7 @@ asmlinkage long sys_pkey_mprotect(unsigned long start, size_t len,
>  				  unsigned long prot, int pkey);
>  asmlinkage long sys_pkey_alloc(unsigned long flags, unsigned long init_val);
>  asmlinkage long sys_pkey_free(int pkey);
> +asmlinkage long sys_statx(int dfd, const char __user *path, unsigned flags,
> +			  unsigned mask, struct statx __user *buffer);
>  
>  #endif
> diff --git a/include/uapi/linux/fcntl.h b/include/uapi/linux/fcntl.h
> index beed138bd359..c49cb6edaafa 100644
> --- a/include/uapi/linux/fcntl.h
> +++ b/include/uapi/linux/fcntl.h
> @@ -62,6 +62,8 @@
>  #define AT_SYMLINK_FOLLOW	0x400   /* Follow symbolic links.  */
>  #define AT_NO_AUTOMOUNT		0x800	/* Suppress terminal automount traversal */
>  #define AT_EMPTY_PATH		0x1000	/* Allow empty relative pathname */
> +#define AT_STATX_FORCE_SYNC	0x2000	/* Force the attributes to be sync'd with the server */
> +#define AT_STATX_DONT_SYNC	0x4000	/* Don't sync attributes with the server */
>  
>  
>  #endif /* _UAPI_LINUX_FCNTL_H */
> diff --git a/include/uapi/linux/stat.h b/include/uapi/linux/stat.h
> index 7fec7e36d921..32ea14c1c960 100644
> --- a/include/uapi/linux/stat.h
> +++ b/include/uapi/linux/stat.h
> @@ -1,6 +1,7 @@
>  #ifndef _UAPI_LINUX_STAT_H
>  #define _UAPI_LINUX_STAT_H
>  
> +#include <linux/types.h>
>  
>  #if defined(__KERNEL__) || !defined(__GLIBC__) || (__GLIBC__ < 2)
>  
> @@ -41,5 +42,128 @@
>  
>  #endif
>  
> +/*
> + * Structures for the extended file attribute retrieval system call
> + * (statx()).
> + *
> + * The caller passes a mask of what they're specifically interested in as a
> + * parameter to statx().  What statx() actually got will be indicated in
> + * st_mask upon return.
> + *
> + * For each bit in the mask argument:
> + *
> + * - if the datum is not supported:
> + *
> + *   - the bit will be cleared, and
> + *
> + *   - the datum will be set to an appropriate fabricated value if one is
> + *     available (eg. CIFS can take a default uid and gid), otherwise
> + *
> + *   - the field will be cleared;
> + *
> + * - otherwise, if explicitly requested:
> + *
> + *   - the datum will be synchronised to the server if AT_STATX_FORCE_SYNC is
> + *     set or if the datum is considered out of date, and
> + *
> + *   - the field will be filled in and the bit will be set;
> + *
> + * - otherwise, if not requested, but available in approximate form without any
> + *   effort, it will be filled in anyway, and the bit will be set upon return
> + *   (it might not be up to date, however, and no attempt will be made to
> + *   synchronise the internal state first);
> + *
> + * - otherwise the field and the bit will be cleared before returning.
> + *
> + * Items in STATX_BASIC_STATS may be marked unavailable on return, but they
> + * will have values installed for compatibility purposes so that stat() and
> + * co. can be emulated in userspace.
> + */
> +struct statx {
> +	/* 0x00 */
> +	__u32	stx_mask;	/* What results were written [uncond] */
> +	__u32	stx_blksize;	/* Preferred general I/O size [uncond] */
> +	__u64	stx_attributes;	/* Flags conveying information about the file [uncond] */
> +	/* 0x10 */
> +	__u32	stx_nlink;	/* Number of hard links */
> +	__u32	stx_uid;	/* User ID of owner */
> +	__u32	stx_gid;	/* Group ID of owner */
> +	__u16	stx_mode;	/* File mode */
> +	__u16	__spare0[1];
> +	/* 0x20 */
> +	__u64	stx_ino;	/* Inode number */
> +	__u64	stx_size;	/* File size */
> +	__u64	stx_blocks;	/* Number of 512-byte blocks allocated */
> +	__u64	stx_version;	/* Data version number */
> +	/* 0x40 */
> +	__s64	stx_atime_s;	/* Last access time */
> +	__s64	stx_btime_s;	/* File creation time */
> +	__s64	stx_ctime_s;	/* Last attribute change time */
> +	__s64	stx_mtime_s;	/* Last data modification time */
> +	/* 0x60 */
> +	__s32	stx_atime_ns;	/* Last access time (ns part) */
> +	__s32	stx_btime_ns;	/* File creation time (ns part) */
> +	__s32	stx_ctime_ns;	/* Last attribute change time (ns part) */
> +	__s32	stx_mtime_ns;	/* Last data modification time (ns part) */
> +	/* 0x70 */
> +	__u32	stx_rdev_major;	/* Device ID of special file [if bdev/cdev] */
> +	__u32	stx_rdev_minor;
> +	__u32	stx_dev_major;	/* ID of device containing file [uncond] */
> +	__u32	stx_dev_minor;
> +	/* 0x80 */
> +	__u64	__spare1[16];	/* Spare space for future expansion */
> +	/* 0x100 */
> +};
> +
> +/*
> + * Flags to be stx_mask
> + *
> + * Query request/result mask for statx() and struct statx::stx_mask.
> + *
> + * These bits should be set in the mask argument of statx() to request
> + * particular items when calling statx().
> + */
> +#define STATX_TYPE		0x00000001U	/* Want/got stx_mode & S_IFMT */
> +#define STATX_MODE		0x00000002U	/* Want/got stx_mode & ~S_IFMT */
> +#define STATX_NLINK		0x00000004U	/* Want/got stx_nlink */
> +#define STATX_UID		0x00000008U	/* Want/got stx_uid */
> +#define STATX_GID		0x00000010U	/* Want/got stx_gid */
> +#define STATX_ATIME		0x00000020U	/* Want/got stx_atime */
> +#define STATX_MTIME		0x00000040U	/* Want/got stx_mtime */
> +#define STATX_CTIME		0x00000080U	/* Want/got stx_ctime */
> +#define STATX_INO		0x00000100U	/* Want/got stx_ino */
> +#define STATX_SIZE		0x00000200U	/* Want/got stx_size */
> +#define STATX_BLOCKS		0x00000400U	/* Want/got stx_blocks */
> +#define STATX_BASIC_STATS	0x000007ffU	/* The stuff in the normal stat struct */
> +#define STATX_BTIME		0x00000800U	/* Want/got stx_btime */
> +#define STATX_VERSION		0x00001000U	/* Want/got stx_version */
> +#define STATX_ALL		0x00001fffU	/* All currently supported flags */
> +
> +/*
> + * Attributes to be found in stx_attributes
> + *
> + * These give information about the features or the state of a file that might
> + * be of use to ordinary userspace programs such as GUIs or ls rather than
> + * specialised tools.
> + *
> + * Note that the flags marked [I] correspond to generic FS_IOC_FLAGS
> + * semantically.  Where possible, the numerical value is picked to correspond
> + * also.
> + */
> +#define STATX_ATTR_COMPRESSED		0x00000004 /* [I] File is compressed by the fs */
> +#define STATX_ATTR_IMMUTABLE		0x00000010 /* [I] File is marked immutable */
> +#define STATX_ATTR_APPEND		0x00000020 /* [I] File is append-only */
> +#define STATX_ATTR_NODUMP		0x00000040 /* [I] File is not to be dumped */
> +#define STATX_ATTR_NONUNIX_OWNERSHIP	0x00000100 /* File has non-Unix ownership details */
> +#define STATX_ATTR_HAS_ACL		0x00000200 /* File has an ACL */
> +#define STATX_ATTR_ENCRYPTED		0x00000800 /* [I] File requires key to decrypt in fs */
> +#define STATX_ATTR_FS_IOC_FLAGS		0x00000874 /* Attrs corresponding to FS_*_FL flags */
> +
> +#define STATX_ATTR_KERNEL_API		0x00001000 /* File is kernel API (eg: procfs/sysfs) */
> +#define STATX_ATTR_REMOTE		0x00002000 /* File is remote and needs network */
> +#define STATX_ATTR_FABRICATED		0x00004000 /* File was made up by fs and is transient */
> +#define STATX_ATTR_AUTOMOUNT		0x00008000 /* Dir: Automount trigger */
> +#define STATX_ATTR_UNLISTED_DENTS	0x00010000 /* Dir: Lookup may find files getdents doesn't */
> +
>  
>  #endif /* _UAPI_LINUX_STAT_H */
> diff --git a/samples/Kconfig b/samples/Kconfig
> index a6d2a43bbf2e..94a7488f14ae 100644
> --- a/samples/Kconfig
> +++ b/samples/Kconfig
> @@ -105,4 +105,9 @@ config SAMPLE_BLACKFIN_GPTIMERS
>  	help
>  	  Build samples of blackfin gptimers sample module.
>  
> +config SAMPLE_STATX
> +	bool "Build example extended-stat using code"
> +	help
> +	  Build example userspace program to use the new extended-stat syscall.
> +
>  endif # SAMPLES
> diff --git a/samples/Makefile b/samples/Makefile
> index e17d66d77f09..8eeb15e13413 100644
> --- a/samples/Makefile
> +++ b/samples/Makefile
> @@ -2,4 +2,5 @@
>  
>  obj-$(CONFIG_SAMPLES)	+= kobject/ kprobes/ trace_events/ livepatch/ \
>  			   hw_breakpoint/ kfifo/ kdb/ hidraw/ rpmsg/ seccomp/ \
> -			   configfs/ connector/ v4l/ trace_printk/ blackfin/
> +			   configfs/ connector/ v4l/ trace_printk/ blackfin/ \
> +			   statx/
> diff --git a/samples/statx/Makefile b/samples/statx/Makefile
> new file mode 100644
> index 000000000000..1f80a3d8cf45
> --- /dev/null
> +++ b/samples/statx/Makefile
> @@ -0,0 +1,10 @@
> +# kbuild trick to avoid linker error. Can be omitted if a module is built.
> +obj- := dummy.o
> +
> +# List of programs to build
> +hostprogs-$(CONFIG_SAMPLE_STATX) := test-statx
> +
> +# Tell kbuild to always build the programs
> +always := $(hostprogs-y)
> +
> +HOSTCFLAGS_test-statx.o += -I$(objtree)/usr/include
> diff --git a/samples/statx/test-statx.c b/samples/statx/test-statx.c
> new file mode 100644
> index 000000000000..2419b33fc15d
> --- /dev/null
> +++ b/samples/statx/test-statx.c
> @@ -0,0 +1,248 @@
> +/* Test the statx() system call
> + *
> + * Copyright (C) 2015 Red Hat, Inc. All Rights Reserved.
> + * Written by David Howells (dhowells@redhat.com)
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public Licence
> + * as published by the Free Software Foundation; either version
> + * 2 of the Licence, or (at your option) any later version.
> + */
> +
> +#define _GNU_SOURCE
> +#define _ATFILE_SOURCE
> +#include <stdio.h>
> +#include <stdlib.h>
> +#include <string.h>
> +#include <unistd.h>
> +#include <ctype.h>
> +#include <errno.h>
> +#include <time.h>
> +#include <sys/syscall.h>
> +#include <sys/types.h>
> +#include <linux/stat.h>
> +#include <linux/fcntl.h>
> +#include <sys/stat.h>
> +
> +#define AT_STATX_FORCE_SYNC	0x2000
> +#define AT_STATX_DONT_SYNC	0x4000
> +
> +static __attribute__((unused))
> +ssize_t statx(int dfd, const char *filename, unsigned flags,
> +	      unsigned int mask, struct statx *buffer)
> +{
> +	return syscall(__NR_statx, dfd, filename, flags, mask, buffer);
> +}
> +
> +static void print_time(const char *field, __s64 tv_sec, __s32 tv_nsec)
> +{
> +	struct tm tm;
> +	time_t tim;
> +	char buffer[100];
> +	int len;
> +
> +	tim = tv_sec;
> +	if (!localtime_r(&tim, &tm)) {
> +		perror("localtime_r");
> +		exit(1);
> +	}
> +	len = strftime(buffer, 100, "%F %T", &tm);
> +	if (len == 0) {
> +		perror("strftime");
> +		exit(1);
> +	}
> +	printf("%s", field);
> +	fwrite(buffer, 1, len, stdout);
> +	printf(".%09u", tv_nsec);
> +	len = strftime(buffer, 100, "%z", &tm);
> +	if (len == 0) {
> +		perror("strftime2");
> +		exit(1);
> +	}
> +	fwrite(buffer, 1, len, stdout);
> +	printf("\n");
> +}
> +
> +static void dump_statx(struct statx *stx)
> +{
> +	char buffer[256], ft = '?';
> +
> +	printf("results=%x\n", stx->stx_mask);
> +
> +	printf(" ");
> +	if (stx->stx_mask & STATX_SIZE)
> +		printf(" Size: %-15llu", (unsigned long long)stx->stx_size);
> +	if (stx->stx_mask & STATX_BLOCKS)
> +		printf(" Blocks: %-10llu", (unsigned long long)stx->stx_blocks);
> +	printf(" IO Block: %-6llu ", (unsigned long long)stx->stx_blksize);
> +	if (stx->stx_mask & STATX_MODE) {
> +		switch (stx->stx_mode & S_IFMT) {
> +		case S_IFIFO:	printf(" FIFO\n");			ft = 'p'; break;
> +		case S_IFCHR:	printf(" character special file\n");	ft = 'c'; break;
> +		case S_IFDIR:	printf(" directory\n");			ft = 'd'; break;
> +		case S_IFBLK:	printf(" block special file\n");	ft = 'b'; break;
> +		case S_IFREG:	printf(" regular file\n");		ft = '-'; break;
> +		case S_IFLNK:	printf(" symbolic link\n");		ft = 'l'; break;
> +		case S_IFSOCK:	printf(" socket\n");			ft = 's'; break;
> +		default:
> +			printf("unknown type (%o)\n", stx->stx_mode & S_IFMT);
> +			break;
> +		}
> +	}
> +
> +	sprintf(buffer, "%02x:%02x", stx->stx_dev_major, stx->stx_dev_minor);
> +	printf("Device: %-15s", buffer);
> +	if (stx->stx_mask & STATX_INO)
> +		printf(" Inode: %-11llu", (unsigned long long) stx->stx_ino);
> +	if (stx->stx_mask & STATX_SIZE)
> +		printf(" Links: %-5u", stx->stx_nlink);
> +	switch (stx->stx_mask & STATX_MODE) {
> +	case S_IFBLK:
> +	case S_IFCHR:
> +		printf(" Device type: %u,%u", stx->stx_rdev_major, stx->stx_rdev_minor);
> +		break;
> +	}
> +	printf("\n");
> +
> +	if (stx->stx_mask & STATX_MODE)
> +		printf("Access: (%04o/%c%c%c%c%c%c%c%c%c%c)  ",
> +		       stx->stx_mode & 07777,
> +		       ft,
> +		       stx->stx_mode & S_IRUSR ? 'r' : '-',
> +		       stx->stx_mode & S_IWUSR ? 'w' : '-',
> +		       stx->stx_mode & S_IXUSR ? 'x' : '-',
> +		       stx->stx_mode & S_IRGRP ? 'r' : '-',
> +		       stx->stx_mode & S_IWGRP ? 'w' : '-',
> +		       stx->stx_mode & S_IXGRP ? 'x' : '-',
> +		       stx->stx_mode & S_IROTH ? 'r' : '-',
> +		       stx->stx_mode & S_IWOTH ? 'w' : '-',
> +		       stx->stx_mode & S_IXOTH ? 'x' : '-');
> +	if (stx->stx_mask & STATX_UID)
> +		printf("Uid: %5d   ", stx->stx_uid);
> +	if (stx->stx_mask & STATX_GID)
> +		printf("Gid: %5d\n", stx->stx_gid);
> +
> +	if (stx->stx_mask & STATX_ATIME)
> +		print_time("Access: ", stx->stx_atime_s, stx->stx_atime_ns);
> +	if (stx->stx_mask & STATX_MTIME)
> +		print_time("Modify: ", stx->stx_mtime_s, stx->stx_mtime_ns);
> +	if (stx->stx_mask & STATX_CTIME)
> +		print_time("Change: ", stx->stx_ctime_s, stx->stx_ctime_ns);
> +	if (stx->stx_mask & STATX_BTIME)
> +		print_time(" Birth: ", stx->stx_btime_s, stx->stx_btime_ns);
> +
> +	if (stx->stx_mask & STATX_VERSION)
> +		printf("Data version: %llxh\n",
> +		       (unsigned long long)stx->stx_version);
> +
> +	if (stx->stx_attributes) {
> +		unsigned char bits;
> +		int loop, byte;
> +
> +		static char attr_representation[64 + 1] =
> +			/* STATX_ATTR_ flags: */
> +			"????????"	/* 63-56 */
> +			"????????"	/* 55-48 */
> +			"????????"	/* 47-40 */
> +			"????????"	/* 39-32 */
> +			"????????"	/* 31-24	0x00000000-ff000000 */
> +			"???????u"	/* 23-16	0x00000000-00ff0000 */
> +			"mfrke?AU"	/* 15- 8	0x00000000-0000ff00 */
> +			"?dai?c??"	/*  7- 0	0x00000000-000000ff */
> +			;
> +
> +		printf("Attributes: %016llx (", stx->stx_attributes);
> +		for (byte = 64 - 8; byte >= 0; byte -= 8) {
> +			bits = stx->stx_attributes >> byte;
> +			for (loop = 7; loop >= 0; loop--) {
> +				int bit = byte + loop;
> +
> +				if (bits & 0x80)
> +					putchar(attr_representation[63 - bit]);
> +				else
> +					putchar('-');
> +				bits <<= 1;
> +			}
> +			if (byte)
> +				putchar(' ');
> +		}
> +		printf(")\n");
> +	}
> +
> +	printf("IO-blocksize: blksize=%u\n", stx->stx_blksize);
> +}
> +
> +static void dump_hex(unsigned long long *data, int from, int to)
> +{
> +	unsigned offset, print_offset = 1, col = 0;
> +
> +	from /= 8;
> +	to = (to + 7) / 8;
> +
> +	for (offset = from; offset < to; offset++) {
> +		if (print_offset) {
> +			printf("%04x: ", offset * 8);
> +			print_offset = 0;
> +		}
> +		printf("%016llx", data[offset]);
> +		col++;
> +		if ((col & 3) == 0) {
> +			printf("\n");
> +			print_offset = 1;
> +		} else {
> +			printf(" ");
> +		}
> +	}
> +
> +	if (!print_offset)
> +		printf("\n");
> +}
> +
> +int main(int argc, char **argv)
> +{
> +	struct statx stx;
> +	int ret, raw = 0, atflag = AT_SYMLINK_NOFOLLOW;
> +
> +	unsigned int mask = STATX_ALL;
> +
> +	for (argv++; *argv; argv++) {
> +		if (strcmp(*argv, "-F") == 0) {
> +			atflag |= AT_STATX_FORCE_SYNC;
> +			continue;
> +		}
> +		if (strcmp(*argv, "-D") == 0) {
> +			atflag |= AT_STATX_DONT_SYNC;
> +			continue;
> +		}
> +		if (strcmp(*argv, "-L") == 0) {
> +			atflag &= ~AT_SYMLINK_NOFOLLOW;
> +			continue;
> +		}
> +		if (strcmp(*argv, "-O") == 0) {
> +			mask &= ~STATX_BASIC_STATS;
> +			continue;
> +		}
> +		if (strcmp(*argv, "-A") == 0) {
> +			atflag |= AT_NO_AUTOMOUNT;
> +			continue;
> +		}
> +		if (strcmp(*argv, "-R") == 0) {
> +			raw = 1;
> +			continue;
> +		}
> +
> +		memset(&stx, 0xbf, sizeof(stx));
> +		ret = statx(AT_FDCWD, *argv, atflag, mask, &stx);
> +		printf("statx(%s) = %d\n", *argv, ret);
> +		if (ret < 0) {
> +			perror(*argv);
> +			exit(1);
> +		}
> +
> +		if (raw)
> +			dump_hex((unsigned long long *)&stx, 0, sizeof(stx));
> +
> +		dump_statx(&stx);
> +	}
> +	return 0;
> +}
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Jeff Layton <jlayton@redhat.com>

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [RFC][PATCH 0/4] Enhanced file stat system call
  2016-11-17 16:45 ` David Howells
@ 2016-11-17 20:00   ` J. Bruce Fields
  2016-11-18  2:30     ` Andreas Dilger
  2016-11-18 13:41   ` One Thousand Gnomes
  2016-11-18 13:49   ` David Howells
  2 siblings, 1 reply; 52+ messages in thread
From: J. Bruce Fields @ 2016-11-17 20:00 UTC (permalink / raw)
  To: David Howells; +Cc: One Thousand Gnomes, linux-fsdevel, linux-kernel

On Thu, Nov 17, 2016 at 04:45:45PM +0000, David Howells wrote:
> One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> wrote:
> 
> > >  (2) Lightweight stat (AT_STATX_DONT_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_STATX_FORCE_SYNC): Force a network fs to flush
> > >      buffers and go to the server, even if it thinks its cached attributes
> > >      are up to date.
> > 
> > That seems an odd way to do it. Wouldn't it be cleaner and more flexible
> > to give a timestamp of the oldest time you consider acceptable (and
> > obviously passing 0 indicates whatever you have)
> 
> Perhaps, though adding 6-argument syscalls is apparently frowned upon.
> 
> > > 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.
> > 
> > and dfd + a name gives you fstatat() ?
> 
> Yes.
> 
> > The cover note could be clearer on this.
> 
> Fixed.
> 
> > Should the fields really be split the way they are for times rather than
> > a struct for each one so you can write code generically to handle one of
> > those rather than having to have a 4 way switch statement all the time.
> 
> It depends.  Doing so leaves 16 bytes of hole in the structure.  I could
> ameliorate the wastage by using a union to overlay useful fields in the gaps,
> but that's pretty icky and might be compiler dependent.
> 
> > Another attribute that would be nice (but migt need some trivial device
> > layer tweaking) would be STATX_ATTR_VOLATILE for filesystems that will
> > probably evaporate on a reboot. That's useful information for tools like
> > installers and also for sanity checking things like backup paths.
> 
> There's a FILE_ATTRIBUTE_TEMPORARY that I could map for windows filesystems
> that could be used with this.
> 
> > Remote needs to have clear semantics: is ext4fs over nbd 'remote' for
> > example ?
> 
> Hmmm... Interesting question.  Probably should.  But you could be insane and
> RAID an nbd and a local disk.  Further, does NFS over a loopback device to
> nfsd on the same machine qualify as root?  What if that's exposing a local fs
> on NBD?  Perhaps I should drop 'REMOTE' for now.  It sounds like something
> that a GUI filemanager might find interesting, though.

Sorry, I haven't been paying attention, just popping up for this, but:
"shared" might be a more useful term than "remote".

A filesystem that may be mounted from more than one system is "shared".
Caching performance and semantics of such a filesystem are more
complicated since the filesystem may change out from under us.  This is
what makes e.g. the lightweight/heavyweight stat difference more
interesting in the shared case.

The filesystem should be able to make that shared/unshared distinction
without knowledge of the storage it's sitting on top of.

Answering your questions by that criterion:

	- ext4/nbd: not shared
	- nfs/lo: shared

But, it's fine with me to drop any features for now as long as we can
always add them later.

--b.

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available
  2016-11-17 13:35 ` [PATCH 1/4] statx: Add a system call to make enhanced file info available David Howells
  2016-11-17 18:39   ` Jeff Layton
@ 2016-11-17 23:40   ` Dave Chinner
  2016-11-18  3:28     ` Andreas Dilger
  2016-11-18  9:53     ` David Howells
  2016-11-18  8:48   ` David Howells
                     ` (3 subsequent siblings)
  5 siblings, 2 replies; 52+ messages in thread
From: Dave Chinner @ 2016-11-17 23:40 UTC (permalink / raw)
  To: David Howells; +Cc: linux-fsdevel, linux-kernel

On Thu, Nov 17, 2016 at 01:35:03PM +0000, David Howells wrote:
> Add a system call to make extended file information available, including
> file creation, data version and some attribute flags where available
> through the underlying filesystem.
> 
> 
> ========
> OVERVIEW
> ========
> 
> The idea was initially proposed as a set of xattrs that could be retrieved
> with getxattr(), but the general preferance proved to be for a new syscall
> with an extended stat structure.
> 
> This has a number of uses:
> 
....
>  (5) Data version number: Could be used by userspace NFS servers [Aneesh
>      Kumar].
> 
>      Can also be used to modify fill_post_wcc() in NFSD which retrieves
>      i_version directly, but has just called vfs_getattr().  It could get
>      it from the kstat struct if it used vfs_xgetattr() instead.

This needs a much clearer name that stx_version as "version" is
entirely ambiguous. e.g. Inodes have internal version numbers to
disambiguate life cycles. and there are versioning filesystems
which have multiple versions of the same file. 

So if stx_version this is intended to export the internal filesystem
inode change counter (i.e. inode->i_version) then lets call it that:
stx_modification_count. It's clear and unambiguous as to what it
represents, especially as this counter is more than just a "data
modification" counter - inode metadata modifications will also
cause it to change....


....

> (13) FS_IOC_GETFLAGS value.  These could be translated to BSD's st_flags.
>      Note that the Linux IOC flags are a mess and filesystems such as Ext4
>      define flags that aren't in linux/fs.h, so translation in the kernel
>      may be a necessity (or, possibly, we provide the filesystem type too).

And we now also have FS_IOC_FSGETXATTR that extends the flags
and information userspace can get from filesystems. It makes little
sense to now add xstat() and not add everything this interface
also exports...

> The defined bits in request_mask and stx_mask are:
> 
> 	STATX_TYPE		Want/got stx_mode & S_IFMT
> 	STATX_MODE		Want/got stx_mode & ~S_IFMT
> 	STATX_NLINK		Want/got stx_nlink
> 	STATX_UID		Want/got stx_uid
> 	STATX_GID		Want/got stx_gid
> 	STATX_ATIME		Want/got stx_atime{,_ns}
> 	STATX_MTIME		Want/got stx_mtime{,_ns}
> 	STATX_CTIME		Want/got stx_ctime{,_ns}
> 	STATX_INO		Want/got stx_ino
> 	STATX_SIZE		Want/got stx_size
> 	STATX_BLOCKS		Want/got stx_blocks
> 	STATX_BASIC_STATS	[The stuff in the normal stat struct]
> 	STATX_BTIME		Want/got stx_btime{,_ns}
> 	STATX_VERSION		Want/got stx_version
> 	STATX_ALL		[All currently available stuff]

What happens when an application uses STATX_ALL from a future kernel
that defines more flags than are initially supported, and that
application then is run on a kernel that onyl supports the initial
fields?

> stx_btime is the file creation time; stx_version is the data version number
> (i_version); stx_mask is a bitmask indicating the data provided; and
> __spares*[] are where as-yet undefined fields can be placed.
> 
> Time fields are split into separate seconds and nanoseconds fields to make
> packing easier and the granularities can be queried with the filesystem
> info system call.  Note that times will be negative if before 1970; in such
> a case, the nanosecond fields will also be negative if not zero.

So what happens in ten years time when we want to support
femptosecond resolution in the timestamp interface? We've got to
change everything to 64 bit? Shouldn't we just make everything
timestamp related 64 bit?

> 
> The bits defined in the stx_attributes field convey information about a
> file, how it is accessed, where it is and what it does.  The following
> attributes map to FS_*_FL flags and are the same numerical value:

Please isolate the new interface flags completely from the FS_*_FL
values. We should not repeat the mistake of tying values derived
from filesystem specific on-disk values to a user interface. 

> 	STATX_ATTR_COMPRESSED		File is compressed by the fs
> 	STATX_ATTR_IMMUTABLE		File is marked immutable
> 	STATX_ATTR_APPEND		File is append-only
> 	STATX_ATTR_NODUMP		File is not to be dumped
> 	STATX_ATTR_ENCRYPTED		File requires key to decrypt in fs
> 
> The supported flags are listed by:
> 
> 	STATX_ATTR_FS_IOC_FLAGS

Again, we have many more common and extended flags than this.
NOATIME and SYNC are two that immediately come to mind as generic
flags that should be in this...

> 
> [Are any other IOC flags of sufficient general interest to be exposed
> through this interface?]
> 
> New flags include:
> 
> 	STATX_ATTR_NONUNIX_OWNERSHIP	File doesn't have Unixy ownership
> 	STATX_ATTR_HAS_ACL		File has an ACL

So statx will require us to do ACL lookups? i.e. instead of just
reading the inode to get the information, we'll also have to do
extended attribute lookups? That's potentially very expensive if
the extended attribute is not stored in the inode....

> 	STATX_ATTR_KERNEL_API		File is kernel API (eg: procfs/sysfs)
> 	STATX_ATTR_REMOTE		File is remote and needs network
> 	STATX_ATTR_FABRICATED		File was made up by fs

Every file is fabricated by a filesystem :P

Perhaps you're wanting "virtual file" because it is has no physical
presence?

> Fields in struct statx come in a number of classes:
> 
>  (0) stx_dev_*, stx_blksize.
> 
>      These are local system information and are always available.

What does stx_blksize actually mean? It's completely ambiguous in
stat() because we don't actually report the physical block size
here - we report the "minimum unit of efficient IO" that we expect
applications to use. Please define :P


> =======
> TESTING
> =======
> 
> The following test program can be used to test the statx system call:
> 
> 	samples/statx/test-statx.c
> 
> Just compile and run, passing it paths to the files you want to examine.
> The file is built automatically if CONFIG_SAMPLES is enabled.

Can we get xfstests written to exercise and validate all this
functionality, please? I'd suggest that adding xfs_io support for
the statx syscall would be far more useful for xfstests than a
standalone  test program, too. We already have equivalent stat()
functionality in xfs_io and that's used quite a bit in xfstests....

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [RFC][PATCH 0/4] Enhanced file stat system call
  2016-11-17 20:00   ` J. Bruce Fields
@ 2016-11-18  2:30     ` Andreas Dilger
  2016-11-18  4:29       ` NeilBrown
  0 siblings, 1 reply; 52+ messages in thread
From: Andreas Dilger @ 2016-11-18  2:30 UTC (permalink / raw)
  To: J. Bruce Fields
  Cc: David Howells, One Thousand Gnomes, linux-fsdevel, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 3696 bytes --]


> On Nov 17, 2016, at 1:00 PM, J. Bruce Fields <bfields@fieldses.org> wrote:
> 
> On Thu, Nov 17, 2016 at 04:45:45PM +0000, David Howells wrote:
>> One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> wrote:
>> 
>>>> (2) Lightweight stat (AT_STATX_DONT_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_STATX_FORCE_SYNC): Force a network fs to flush
>>>>     buffers and go to the server, even if it thinks its cached attributes
>>>>     are up to date.
>>> 
>>> That seems an odd way to do it. Wouldn't it be cleaner and more flexible
>>> to give a timestamp of the oldest time you consider acceptable (and
>>> obviously passing 0 indicates whatever you have)
>> 
>> Perhaps, though adding 6-argument syscalls is apparently frowned upon.
>> 
>>>> 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.
>>> 
>>> and dfd + a name gives you fstatat() ?
>> 
>> Yes.
>> 
>>> The cover note could be clearer on this.
>> 
>> Fixed.
>> 
>>> Should the fields really be split the way they are for times rather than
>>> a struct for each one so you can write code generically to handle one of
>>> those rather than having to have a 4 way switch statement all the time.
>> 
>> It depends.  Doing so leaves 16 bytes of hole in the structure.  I could
>> ameliorate the wastage by using a union to overlay useful fields in the gaps,
>> but that's pretty icky and might be compiler dependent.
>> 
>>> Another attribute that would be nice (but migt need some trivial device
>>> layer tweaking) would be STATX_ATTR_VOLATILE for filesystems that will
>>> probably evaporate on a reboot. That's useful information for tools like
>>> installers and also for sanity checking things like backup paths.
>> 
>> There's a FILE_ATTRIBUTE_TEMPORARY that I could map for windows filesystems
>> that could be used with this.
>> 
>>> Remote needs to have clear semantics: is ext4fs over nbd 'remote' for
>>> example ?
>> 
>> Hmmm... Interesting question.  Probably should.  But you could be insane and
>> RAID an nbd and a local disk.  Further, does NFS over a loopback device to
>> nfsd on the same machine qualify as root?  What if that's exposing a local fs
>> on NBD?  Perhaps I should drop 'REMOTE' for now.  It sounds like something
>> that a GUI filemanager might find interesting, though.
> 
> Sorry, I haven't been paying attention, just popping up for this, but:
> "shared" might be a more useful term than "remote".
> 
> A filesystem that may be mounted from more than one system is "shared".
> Caching performance and semantics of such a filesystem are more
> complicated since the filesystem may change out from under us.  This is
> what makes e.g. the lightweight/heavyweight stat difference more
> interesting in the shared case.
> 
> The filesystem should be able to make that shared/unshared distinction
> without knowledge of the storage it's sitting on top of.
> 
> Answering your questions by that criterion:
> 
> 	- ext4/nbd: not shared
> 	- nfs/lo: shared
> 
> But, it's fine with me to drop any features for now as long as we can
> always add them later.

Please, please, please, let's get the syscall and basic functionality
landed first, and then nit-pick about extensions later.  This has been
dragging on for _years_ and bike shedded to death.

Cheers, Andreas






[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available
  2016-11-17 18:39   ` Jeff Layton
@ 2016-11-18  2:32     ` Andreas Dilger
  2016-11-18  8:59       ` David Howells
  1 sibling, 0 replies; 52+ messages in thread
From: Andreas Dilger @ 2016-11-18  2:32 UTC (permalink / raw)
  To: Jeff Layton; +Cc: David Howells, linux-fsdevel, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 50331 bytes --]


> On Nov 17, 2016, at 11:39 AM, Jeff Layton <jlayton@redhat.com> wrote:
> 
> On Thu, 2016-11-17 at 13:35 +0000, David Howells wrote:
>> Add a system call to make extended file information available, including
>> file creation, data version and some attribute flags where available
>> through the underlying filesystem.
>> 
>> 
>> ========
>> OVERVIEW
>> ========
>> 
>> The idea was initially proposed as a set of xattrs that could be retrieved
>> with getxattr(), but the general preferance proved to be for a new syscall
>> with an extended stat structure.
>> 
>> This has a number of uses:
>> 
>> (1) Better support for the y2038 problem [Arnd Bergmann].
>> 
>> (2) Creation time: The SMB protocol carries the creation time, which could
>>     be exported by Samba, which will in turn help CIFS make use of
>>     FS-Cache as that can be used for coherency data.
>> 
>>     This is also specified in NFSv4 as a recommended attribute and could
>>     be exported by NFSD [Steve French].
>> 
>> (3) Lightweight stat: Ask for just those details of interest, and allow a
>>     netfs (such as NFS) to approximate anything not of interest, possibly
>>     without going to the server [Trond Myklebust, Ulrich Drepper, Andreas
>>     Dilger].
>> 
>> (4) Heavyweight stat: Force a netfs to go to the server, even if it thinks
>>     its cached attributes are up to date [Trond Myklebust].
>> 
>> (5) Data version number: Could be used by userspace NFS servers [Aneesh
>>     Kumar].
>> 
>>     Can also be used to modify fill_post_wcc() in NFSD which retrieves
>>     i_version directly, but has just called vfs_getattr().  It could get
>>     it from the kstat struct if it used vfs_xgetattr() instead.
>> 
>> (6) BSD stat compatibility: Including more fields from the BSD stat such
>>     as creation time (st_btime) and inode generation number (st_gen)
>>     [Jeremy Allison, Bernd Schubert].
>> 
>> (7) Inode generation number: Useful for FUSE and userspace NFS servers
>>     [Bernd Schubert].  This was asked for but later deemed unnecessary
>>     with the open-by-handle capability available
>> 
>> (8) Extra coherency data may be useful in making backups [Andreas Dilger].
>> 
>> (9) 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, so if, for instance, inode numbers or UIDs don't
>>     exist or are fabricated locally...
>> 
>> (10) Make the fields a consistent size on all arches and make them large.
>> 
>> (11) Store a 16-byte volume ID in the superblock that can be returned in
>>     struct xstat [Steve French].
>> 
>> (12) Include granularity fields in the time data to indicate the
>>     granularity of each of the times (NFSv4 time_delta) [Steve French].
>> 
>> (13) FS_IOC_GETFLAGS value.  These could be translated to BSD's st_flags.
>>     Note that the Linux IOC flags are a mess and filesystems such as Ext4
>>     define flags that aren't in linux/fs.h, so translation in the kernel
>>     may be a necessity (or, possibly, we provide the filesystem type too).
>> 
>> (14) Mask of features available on file (eg: ACLs, seclabel) [Brad Boyer,
>>     Michael Kerrisk].
>> 
>> (15) Spare space, request flags and information flags are provided for
>>     future expansion.
>> 
>> Note that not all of the above are implemented here.
>> 
>> 
>> ===============
>> NEW SYSTEM CALL
>> ===============
>> 
>> The new system call is:
>> 
>> 	int ret = statx(int dfd,
>> 			const char *filename,
>> 			unsigned int flags,
>> 			unsigned int mask,
>> 			struct statx *buffer);
>> 
>> The dfd, filename and flags parameters indicate the file to query.  There
>> is no equivalent of lstat() as that can be emulated with statx() by passing
>> AT_SYMLINK_NOFOLLOW in flags.  There is also no equivalent of fstat() as
>> that can be emulated by passing a NULL filename to statx() with the fd of
>> interest in dfd.
>> 
>> AT_STATX_FORCE_SYNC can be set in flags.  This will require a network
>> filesystem to synchronise its attributes with the server.
>> 
>> AT_STATX_DONT_SYNC can be set in flags.  This will suppress synchronisation
>> with the server in a network filesystem.  The resulting values should be
>> considered approximate.
>> 
>> If neither AT_STATX_*_SYNC flag is set, the behaviour is the default for
>> stat() on that filesystem.
>> 
> 
> We also need to specify here what happens if both bits are set. Should
> that be -EINVAL?

If that is the case, then it doesn't make sense to have two contradictory
flags.

Pick a default behaviour (i.e. return what is known on the client), and
if this is 100% accurate (e.g. local filesystem or filesystem with strong
coherency) then it can optionally set the SYNC flag in the returned flags.
If the application needs 100% accurate size info, then it can set the SYNC
flag in the request and the filesystem may need to do extra work to fetch
accurate data from the server.

>> mask is a bitmask indicating the fields in struct statx that are of
>> interest to the caller.  The user should set this to STATX_BASIC_STATS to
>> get the basic set returned by stat().  It should be note that asking for
>> more information may entail more I/O operations.
>> 
>> buffer points to the destination for the data.  This must be 256 bytes in
>> size.
>> 
>> 
>> ======================
>> MAIN ATTRIBUTES RECORD
>> ======================
>> 
>> The following structures are defined in which to return the main attribute
>> set:
>> 
>> 	struct statx {
>> 		__u32	stx_mask;
>> 		__u32	stx_blksize;
>> 		__u64	stx_attributes;
>> 		__u32	stx_nlink;
>> 		__u32	stx_uid;
>> 		__u32	stx_gid;
>> 		__u16	stx_mode;
>> 		__u16	__spare0[1];
>> 		__u64	stx_ino;
>> 		__u64	stx_size;
>> 		__u64	stx_blocks;
>> 		__u64	stx_version;
>> 		__s64	stx_atime;
>> 		__s64	stx_btime;
>> 		__s64	stx_ctime;
>> 		__s64	stx_mtime;
>> 		__s32	stx_atime_ns;
>> 		__s32	stx_btime_ns;
>> 		__s32	stx_ctime_ns;
>> 		__s32	stx_mtime_ns;
>> 		__u32	stx_rdev_major;
>> 		__u32	stx_rdev_minor;
>> 		__u32	stx_dev_major;
>> 		__u32	stx_dev_minor;
>> 		__u64	__spare1[16];
>> 	};
>> 
>> The defined bits in request_mask and stx_mask are:
>> 
>> 	STATX_TYPE		Want/got stx_mode & S_IFMT
>> 	STATX_MODE		Want/got stx_mode & ~S_IFMT
>> 	STATX_NLINK		Want/got stx_nlink
>> 	STATX_UID		Want/got stx_uid
>> 	STATX_GID		Want/got stx_gid
>> 	STATX_ATIME		Want/got stx_atime{,_ns}
>> 	STATX_MTIME		Want/got stx_mtime{,_ns}
>> 	STATX_CTIME		Want/got stx_ctime{,_ns}
>> 	STATX_INO		Want/got stx_ino
>> 	STATX_SIZE		Want/got stx_size
>> 	STATX_BLOCKS		Want/got stx_blocks
>> 	STATX_BASIC_STATS	[The stuff in the normal stat struct]
>> 	STATX_BTIME		Want/got stx_btime{,_ns}
>> 	STATX_VERSION		Want/got stx_version
>> 	STATX_ALL		[All currently available stuff]
>> 
>> stx_btime is the file creation time; stx_version is the data version number
>> (i_version); stx_mask is a bitmask indicating the data provided; and
>> __spares*[] are where as-yet undefined fields can be placed.
>> 
>> Time fields are split into separate seconds and nanoseconds fields to make
>> packing easier and the granularities can be queried with the filesystem
>> info system call.  Note that times will be negative if before 1970; in such
>> a case, the nanosecond fields will also be negative if not zero.
>> 
>> The bits defined in the stx_attributes field convey information about a
>> file, how it is accessed, where it is and what it does.  The following
>> attributes map to FS_*_FL flags and are the same numerical value:
>> 
>> 	STATX_ATTR_COMPRESSED		File is compressed by the fs
>> 	STATX_ATTR_IMMUTABLE		File is marked immutable
>> 	STATX_ATTR_APPEND		File is append-only
>> 	STATX_ATTR_NODUMP		File is not to be dumped
>> 	STATX_ATTR_ENCRYPTED		File requires key to decrypt in fs
>> 
>> The supported flags are listed by:
>> 
>> 	STATX_ATTR_FS_IOC_FLAGS
>> 
>> [Are any other IOC flags of sufficient general interest to be exposed
>> through this interface?]
>> 
>> New flags include:
>> 
>> 	STATX_ATTR_NONUNIX_OWNERSHIP	File doesn't have Unixy ownership
>> 	STATX_ATTR_HAS_ACL		File has an ACL
>> 	STATX_ATTR_KERNEL_API		File is kernel API (eg: procfs/sysfs)
>> 	STATX_ATTR_REMOTE		File is remote and needs network
>> 	STATX_ATTR_FABRICATED		File was made up by fs
>> 	STATX_ATTR_AUTOMOUNT		Object is an automount trigger
>> 	STATX_ATTR_UNLISTED_DENTS	Dir: Lookup may find files getdents doesn't
>> 
>> These are for the use of GUI tools that might want to mark files specially,
>> depending on what they are.
>> 
>> Fields in struct statx come in a number of classes:
>> 
>> (0) stx_dev_*, stx_blksize.
>> 
>>     These are local system information and are always available.
>> 
>> (1) stx_mode, stx_nlinks, stx_uid, stx_gid, stx_[amc]time*, stx_ino,
>>     stx_size, stx_blocks.
>> 
>>     These will be returned whether the caller asks for them or not.  The
>>     corresponding bits in stx_mask will be set to indicate whether they
>>     actually have valid values.
>> 
>>     If the caller didn't ask for them, then they may be approximated.  For
>>     example, NFS won't waste any time updating them from the server,
>>     unless as a byproduct of updating something requested.
>> 
>>     If the values don't actually exist for the underlying object (such as
>>     UID or GID on a DOS file), then the bit won't be set in the stx_mask,
>>     even if the caller asked for the value.  In such a case, the returned
>>     value will be a fabrication.
>> 
>>     Note that there are instances where the type might not be valid, for
>>     instance Windows reparse points.
>> 
>> (2) stx_rdev_*.
>> 
>>     This will be set only if stx_mode indicates we're looking at a
>>     blockdev or a chardev, otherwise will be 0.
>> 
>> (3) stx_btime*, stx_version.
>> 
>>     Similar to (1), except these will be set to 0 if they don't exist.
>> 
>> 
>> =======
>> TESTING
>> =======
>> 
>> The following test program can be used to test the statx system call:
>> 
>> 	samples/statx/test-statx.c
>> 
>> Just compile and run, passing it paths to the files you want to examine.
>> The file is built automatically if CONFIG_SAMPLES is enabled.
>> 
>> Here's some example output.  Firstly, an NFS directory that crosses to
>> another FSID.  Note that the FABRICATED and AUTOMOUNT info flags are set.
>> The former because the directory is invented locally as we don't see the
>> underlying dir on the server, the latter because transiting this directory
>> will cause d_automount to be invoked by the VFS.
>> 
>> 	[root@andromeda tmp]# ./samples/statx/test-statx -A /warthog/data
>> 	statx(/warthog/data) = 0
>> 	results=17ff
>> 	  Size: 4096            Blocks: 8          IO Block: 1048576  directory
>> 	Device: 00:26           Inode: 1703937     Links: 124
>> 	Access: (3777/drwxrwxrwx)  Uid:     0   Gid:  4041
>> 	Access: 2016-11-10 15:52:11.219935864+0000
>> 	Modify: 2016-11-10 08:07:32.482314928+0000
>> 	Change: 2016-11-10 08:07:32.482314928+0000
>> 	Data version: 58242ac41cbf8ab0h
>> 	Attributes: 000000000000e000 (-------- -------- -------- -------- -------- -------- mfr----- --------)
>> 	IO-blocksize: blksize=1048576
>> 
>> Secondly, the result of automounting on that directory.
>> 
>> 	[root@andromeda tmp]# ./samples/statx/test-statx /warthog/data
>> 	statx(/warthog/data) = 0
>> 	results=17ff
>> 	  Size: 4096            Blocks: 8          IO Block: 1048576  directory
>> 	Device: 00:27           Inode: 2           Links: 124
>> 	Access: (3777/drwxrwxrwx)  Uid:     0   Gid:  4041
>> 	Access: 2016-11-10 15:52:11.219935864+0000
>> 	Modify: 2016-11-10 08:07:32.482314928+0000
>> 	Change: 2016-11-10 08:07:32.482314928+0000
>> 	Data version: 58242ac41cbf8ab0h
>> 	Attributes: 0000000000002000 (-------- -------- -------- -------- -------- -------- --r----- --------)
>> 	IO-blocksize: blksize=1048576
>> 
>> Signed-off-by: David Howells <dhowells@redhat.com>
>> ---
>> 
>> arch/x86/entry/syscalls/syscall_32.tbl |    1
>> arch/x86/entry/syscalls/syscall_64.tbl |    1
>> fs/exportfs/expfs.c                    |    4
>> fs/stat.c                              |  294 +++++++++++++++++++++++++++++---
>> include/linux/fs.h                     |    5 -
>> include/linux/stat.h                   |   19 +-
>> include/linux/syscalls.h               |    3
>> include/uapi/linux/fcntl.h             |    2
>> include/uapi/linux/stat.h              |  124 +++++++++++++
>> samples/Kconfig                        |    5 +
>> samples/Makefile                       |    3
>> samples/statx/Makefile                 |   10 +
>> samples/statx/test-statx.c             |  248 +++++++++++++++++++++++++++
>> 13 files changed, 679 insertions(+), 40 deletions(-)
>> create mode 100644 samples/statx/Makefile
>> create mode 100644 samples/statx/test-statx.c
>> 
>> diff --git a/arch/x86/entry/syscalls/syscall_32.tbl b/arch/x86/entry/syscalls/syscall_32.tbl
>> index 2b3618542544..9ba050fe47f3 100644
>> --- a/arch/x86/entry/syscalls/syscall_32.tbl
>> +++ b/arch/x86/entry/syscalls/syscall_32.tbl
>> @@ -389,3 +389,4 @@
>> 380	i386	pkey_mprotect		sys_pkey_mprotect
>> 381	i386	pkey_alloc		sys_pkey_alloc
>> 382	i386	pkey_free		sys_pkey_free
>> +383	i386	statx			sys_statx
>> diff --git a/arch/x86/entry/syscalls/syscall_64.tbl b/arch/x86/entry/syscalls/syscall_64.tbl
>> index e93ef0b38db8..5aef183e2f85 100644
>> --- a/arch/x86/entry/syscalls/syscall_64.tbl
>> +++ b/arch/x86/entry/syscalls/syscall_64.tbl
>> @@ -338,6 +338,7 @@
>> 329	common	pkey_mprotect		sys_pkey_mprotect
>> 330	common	pkey_alloc		sys_pkey_alloc
>> 331	common	pkey_free		sys_pkey_free
>> +332	common	statx			sys_statx
>> 
>> #
>> # x32-specific system call numbers start at 512 to avoid cache impact
>> diff --git a/fs/exportfs/expfs.c b/fs/exportfs/expfs.c
>> index a4b531be9168..2acc31751248 100644
>> --- a/fs/exportfs/expfs.c
>> +++ b/fs/exportfs/expfs.c
>> @@ -299,7 +299,9 @@ static int get_name(const struct path *path, char *name, struct dentry *child)
>> 	 * filesystem supports 64-bit inode numbers.  So we need to
>> 	 * actually call ->getattr, not just read i_ino:
>> 	 */
>> -	error = vfs_getattr_nosec(&child_path, &stat);
>> +	stat.query_flags = 0;
>> +	stat.request_mask = STATX_BASIC_STATS;
>> +	error = vfs_xgetattr_nosec(&child_path, &stat);
>> 	if (error)
>> 		return error;
>> 	buffer.ino = stat.ino;
>> diff --git a/fs/stat.c b/fs/stat.c
>> index bc045c7994e1..78c0a5086038 100644
>> --- a/fs/stat.c
>> +++ b/fs/stat.c
>> @@ -18,6 +18,15 @@
>> #include <asm/uaccess.h>
>> #include <asm/unistd.h>
>> 
>> +/**
>> + * generic_fillattr - Fill in the basic attributes from the inode struct
>> + * @inode: Inode to use as the source
>> + * @stat: Where to fill in the attributes
>> + *
>> + * Fill in the basic attributes in the kstat structure from data that's to be
>> + * found on the VFS inode structure.  This is the default if no getattr inode
>> + * operation is supplied.
>> + */
>> void generic_fillattr(struct inode *inode, struct kstat *stat)
>> {
>> 	stat->dev = inode->i_sb->s_dev;
>> @@ -27,87 +36,189 @@ void generic_fillattr(struct inode *inode, struct kstat *stat)
>> 	stat->uid = inode->i_uid;
>> 	stat->gid = inode->i_gid;
>> 	stat->rdev = inode->i_rdev;
>> -	stat->size = i_size_read(inode);
>> -	stat->atime = inode->i_atime;
>> 	stat->mtime = inode->i_mtime;
>> 	stat->ctime = inode->i_ctime;
>> -	stat->blksize = (1 << inode->i_blkbits);
>> +	stat->size = i_size_read(inode);
>> 	stat->blocks = inode->i_blocks;
>> -}
>> +	stat->blksize = 1 << inode->i_blkbits;
>> 
>> +	stat->result_mask |= STATX_BASIC_STATS;
>> +	if (IS_NOATIME(inode))
>> +		stat->result_mask &= ~STATX_ATIME;
>> +	else
>> +		stat->atime = inode->i_atime;
>> +
>> +	if (IS_AUTOMOUNT(inode))
>> +		stat->attributes |= STATX_ATTR_AUTOMOUNT;
>> +}
>> EXPORT_SYMBOL(generic_fillattr);
>> 
>> /**
>> - * vfs_getattr_nosec - getattr without security checks
>> + * vfs_xgetattr_nosec - getattr without security checks
>>  * @path: file to get attributes from
>>  * @stat: structure to return attributes in
>>  *
>>  * Get attributes without calling security_inode_getattr.
>>  *
>> - * Currently the only caller other than vfs_getattr is internal to the
>> - * filehandle lookup code, which uses only the inode number and returns
>> - * no attributes to any user.  Any other code probably wants
>> - * vfs_getattr.
>> + * Currently the only caller other than vfs_xgetattr is internal to the
>> + * filehandle lookup code, which uses only the inode number and returns no
>> + * attributes to any user.  Any other code probably wants vfs_xgetattr.
>> + *
>> + * The caller must set stat->request_mask to indicate what they want and
>> + * stat->query_flags to indicate whether the server should be queried.
>>  */
>> -int vfs_getattr_nosec(struct path *path, struct kstat *stat)
>> +int vfs_xgetattr_nosec(struct path *path, struct kstat *stat)
>> {
>> 	struct inode *inode = d_backing_inode(path->dentry);
>> 
>> +	stat->query_flags &= ~KSTAT_QUERY_FLAGS;
>> +
>> +	stat->result_mask = 0;
>> +	stat->attributes = 0;
>> 	if (inode->i_op->getattr)
>> 		return inode->i_op->getattr(path->mnt, path->dentry, stat);
>> 
>> 	generic_fillattr(inode, stat);
>> 	return 0;
>> }
>> +EXPORT_SYMBOL(vfs_xgetattr_nosec);
>> 
>> -EXPORT_SYMBOL(vfs_getattr_nosec);
>> -
>> -int vfs_getattr(struct path *path, struct kstat *stat)
>> +/*
>> + * vfs_xgetattr - Get the enhanced basic attributes of a file
>> + * @path: The file of interest
>> + * @stat: Where to return the statistics
>> + *
>> + * Ask the filesystem for a file's attributes.  The caller must have preset
>> + * stat->request_mask and stat->query_flags to indicate what they want.
>> + *
>> + * If the file is remote, the filesystem can be forced to update the attributes
>> + * from the backing store by passing AT_FORCE_ATTR_SYNC in query_flags or can
>> + * suppress the update by passing AT_NO_ATTR_SYNC.
>> + *
>> + * Bits must have been set in stat->request_mask to indicate which attributes
>> + * the caller wants retrieving.  Any such attribute not requested may be
>> + * returned anyway, but the value may be approximate, and, if remote, may not
>> + * have been synchronised with the server.
>> + *
>> + * 0 will be returned on success, and a -ve error code if unsuccessful.
>> + */
>> +int vfs_xgetattr(struct path *path, struct kstat *stat)
>> {
>> 	int retval;
>> 
>> 	retval = security_inode_getattr(path);
>> 	if (retval)
>> 		return retval;
>> -	return vfs_getattr_nosec(path, stat);
>> +	return vfs_xgetattr_nosec(path, stat);
>> }
>> +EXPORT_SYMBOL(vfs_xgetattr);
>> 
>> +/**
>> + * vfs_getattr - Get the basic attributes of a file
>> + * @path: The file of interest
>> + * @stat: Where to return the statistics
>> + *
>> + * Ask the filesystem for a file's attributes.  If remote, the filesystem isn't
>> + * forced to update its files from the backing store.  Only the basic set of
>> + * attributes will be retrieved; anyone wanting more must use vfs_xgetattr(),
>> + * as must anyone who wants to force attributes to be sync'd with the server.
>> + *
>> + * 0 will be returned on success, and a -ve error code if unsuccessful.
>> + */
>> +int vfs_getattr(struct path *path, struct kstat *stat)
>> +{
>> +	stat->query_flags = 0;
>> +	stat->request_mask = STATX_BASIC_STATS;
>> +	return vfs_xgetattr(path, stat);
>> +}
>> EXPORT_SYMBOL(vfs_getattr);
>> 
>> -int vfs_fstat(unsigned int fd, struct kstat *stat)
>> +/**
>> + * vfs_fstatx - Get the enhanced basic attributes by file descriptor
>> + * @fd: The file descriptor referring to the file of interest
>> + * @stat: The result structure to fill in.
>> + *
>> + * This function is a wrapper around vfs_xgetattr().  The main difference is
>> + * that it uses a file descriptor to determine the file location.
>> + *
>> + * The caller must have preset stat->query_flags and stat->request_mask as for
>> + * vfs_xgetattr().
>> + *
>> + * 0 will be returned on success, and a -ve error code if unsuccessful.
>> + */
>> +int vfs_fstatx(unsigned int fd, struct kstat *stat)
>> {
>> 	struct fd f = fdget_raw(fd);
>> 	int error = -EBADF;
>> 
>> 	if (f.file) {
>> -		error = vfs_getattr(&f.file->f_path, stat);
>> +		error = vfs_xgetattr(&f.file->f_path, stat);
>> 		fdput(f);
>> 	}
>> 	return error;
>> }
>> +EXPORT_SYMBOL(vfs_fstatx);
>> +
>> +/**
>> + * vfs_fstat - Get basic attributes by file descriptor
>> + * @fd: The file descriptor referring to the file of interest
>> + * @stat: The result structure to fill in.
>> + *
>> + * This function is a wrapper around vfs_getattr().  The main difference is
>> + * that it uses a file descriptor to determine the file location.
>> + *
>> + * 0 will be returned on success, and a -ve error code if unsuccessful.
>> + */
>> +int vfs_fstat(unsigned int fd, struct kstat *stat)
>> +{
>> +	stat->query_flags = 0;
>> +	stat->request_mask = STATX_BASIC_STATS;
>> +	return vfs_fstatx(fd, stat);
>> +}
>> EXPORT_SYMBOL(vfs_fstat);
>> 
>> -int vfs_fstatat(int dfd, const char __user *filename, struct kstat *stat,
>> -		int flag)
>> +/**
>> + * vfs_statx - Get basic and extra attributes by filename
>> + * @dfd: A file descriptor representing the base dir for a relative filename
>> + * @filename: The name of the file of interest
>> + * @flags: Flags to control the query
>> + * @stat: The result structure to fill in.
>> + *
>> + * This function is a wrapper around vfs_xgetattr().  The main difference is
>> + * that it uses a filename and base directory to determine the file location.
>> + * Additionally, the addition of AT_SYMLINK_NOFOLLOW to flags will prevent a
>> + * symlink at the given name from being referenced.
>> + *
>> + * The caller must have preset stat->request_mask as for vfs_xgetattr().  The
>> + * flags are also used to load up stat->query_flags.
>> + *
>> + * 0 will be returned on success, and a -ve error code if unsuccessful.
>> + */
>> +int vfs_statx(int dfd, const char __user *filename, int flags,
>> +	      struct kstat *stat)
>> {
>> 	struct path path;
>> 	int error = -EINVAL;
>> -	unsigned int lookup_flags = 0;
>> +	unsigned int lookup_flags = LOOKUP_FOLLOW | LOOKUP_AUTOMOUNT;
>> 
>> -	if ((flag & ~(AT_SYMLINK_NOFOLLOW | AT_NO_AUTOMOUNT |
>> -		      AT_EMPTY_PATH)) != 0)
>> -		goto out;
>> +	if ((flags & ~(AT_SYMLINK_NOFOLLOW | AT_NO_AUTOMOUNT |
>> +		       AT_EMPTY_PATH | KSTAT_QUERY_FLAGS)) != 0)
>> +		return -EINVAL;
>> 
>> -	if (!(flag & AT_SYMLINK_NOFOLLOW))
>> -		lookup_flags |= LOOKUP_FOLLOW;
>> -	if (flag & AT_EMPTY_PATH)
>> +	if (flags & AT_SYMLINK_NOFOLLOW)
>> +		lookup_flags &= ~LOOKUP_FOLLOW;
>> +	if (flags & AT_NO_AUTOMOUNT)
>> +		lookup_flags &= ~LOOKUP_AUTOMOUNT;
>> +	if (flags & AT_EMPTY_PATH)
>> 		lookup_flags |= LOOKUP_EMPTY;
>> +	stat->query_flags = flags;
>> +
>> retry:
>> 	error = user_path_at(dfd, filename, lookup_flags, &path);
>> 	if (error)
>> 		goto out;
>> 
>> -	error = vfs_getattr(&path, stat);
>> +	error = vfs_xgetattr(&path, stat);
>> 	path_put(&path);
>> 	if (retry_estale(error, lookup_flags)) {
>> 		lookup_flags |= LOOKUP_REVAL;
>> @@ -116,17 +227,65 @@ int vfs_fstatat(int dfd, const char __user *filename, struct kstat *stat,
>> out:
>> 	return error;
>> }
>> +EXPORT_SYMBOL(vfs_statx);
>> +
>> +/**
>> + * vfs_fstatat - Get basic attributes by filename
>> + * @dfd: A file descriptor representing the base dir for a relative filename
>> + * @filename: The name of the file of interest
>> + * @flags: Flags to control the query
>> + * @stat: The result structure to fill in.
>> + *
>> + * This function is a wrapper around vfs_statx().  The difference is that it
>> + * preselects basic stats only.  The flags are used to load up
>> + * stat->query_flags in addition to indicating symlink handling during path
>> + * resolution.
>> + *
>> + * 0 will be returned on success, and a -ve error code if unsuccessful.
>> + */
>> +int vfs_fstatat(int dfd, const char __user *filename, struct kstat *stat,
>> +		int flags)
>> +{
>> +	stat->request_mask = STATX_BASIC_STATS;
>> +	return vfs_statx(dfd, filename, flags, stat);
>> +}
>> EXPORT_SYMBOL(vfs_fstatat);
>> 
>> -int vfs_stat(const char __user *name, struct kstat *stat)
>> +/**
>> + * vfs_stat - Get basic attributes by filename
>> + * @filename: The name of the file of interest
>> + * @stat: The result structure to fill in.
>> + *
>> + * This function is a wrapper around vfs_statx().  The difference is that it
>> + * preselects basic stats only, terminal symlinks are followed regardless and a
>> + * remote filesystem can't be forced to query the server.  If such is desired,
>> + * vfs_statx() should be used instead.
>> + *
>> + * 0 will be returned on success, and a -ve error code if unsuccessful.
>> + */
>> +int vfs_stat(const char __user *filename, struct kstat *stat)
>> {
>> -	return vfs_fstatat(AT_FDCWD, name, stat, 0);
>> +	stat->request_mask = STATX_BASIC_STATS;
>> +	return vfs_statx(AT_FDCWD, filename, 0, stat);
>> }
>> EXPORT_SYMBOL(vfs_stat);
>> 
>> +/**
>> + * vfs_lstat - Get basic attrs by filename, without following terminal symlink
>> + * @filename: The name of the file of interest
>> + * @stat: The result structure to fill in.
>> + *
>> + * This function is a wrapper around vfs_statx().  The difference is that it
>> + * preselects basic stats only, terminal symlinks are note followed regardless
>> + * and a remote filesystem can't be forced to query the server.  If such is
>> + * desired, vfs_statx() should be used instead.
>> + *
>> + * 0 will be returned on success, and a -ve error code if unsuccessful.
>> + */
>> int vfs_lstat(const char __user *name, struct kstat *stat)
>> {
>> -	return vfs_fstatat(AT_FDCWD, name, stat, AT_SYMLINK_NOFOLLOW);
>> +	stat->request_mask = STATX_BASIC_STATS;
>> +	return vfs_statx(AT_FDCWD, name, AT_SYMLINK_NOFOLLOW, stat);
>> }
>> EXPORT_SYMBOL(vfs_lstat);
>> 
>> @@ -141,7 +300,7 @@ static int cp_old_stat(struct kstat *stat, struct __old_kernel_stat __user * sta
>> {
>> 	static int warncount = 5;
>> 	struct __old_kernel_stat tmp;
>> -
>> +
>> 	if (warncount > 0) {
>> 		warncount--;
>> 		printk(KERN_WARNING "VFS: Warning: %s using old stat() call. Recompile your binary.\n",
>> @@ -166,7 +325,7 @@ static int cp_old_stat(struct kstat *stat, struct __old_kernel_stat __user * sta
>> #if BITS_PER_LONG == 32
>> 	if (stat->size > MAX_NON_LFS)
>> 		return -EOVERFLOW;
>> -#endif
>> +#endif
>> 	tmp.st_size = stat->size;
>> 	tmp.st_atime = stat->atime.tv_sec;
>> 	tmp.st_mtime = stat->mtime.tv_sec;
>> @@ -443,6 +602,79 @@ SYSCALL_DEFINE4(fstatat64, int, dfd, const char __user *, filename,
>> }
>> #endif /* __ARCH_WANT_STAT64 || __ARCH_WANT_COMPAT_STAT64 */
>> 
>> +/*
>> + * Set the statx results.
>> + */
>> +static long statx_set_result(struct kstat *stat, struct statx __user *buffer)
>> +{
>> +	uid_t uid = from_kuid_munged(current_user_ns(), stat->uid);
>> +	gid_t gid = from_kgid_munged(current_user_ns(), stat->gid);
>> +
>> +#define __put_timestamp(kts, uts) (				\
>> +		__put_user(kts.tv_sec,	uts##_s		) ||	\
>> +		__put_user(kts.tv_nsec,	uts##_ns	))
>> +
>> +	if (__put_user(stat->result_mask,	&buffer->stx_mask	) ||
>> +	    __put_user(stat->mode,		&buffer->stx_mode	) ||
>> +	    __clear_user(&buffer->__spare0, sizeof(buffer->__spare0))	  ||
>> +	    __put_user(stat->nlink,		&buffer->stx_nlink	) ||
>> +	    __put_user(uid,			&buffer->stx_uid	) ||
>> +	    __put_user(gid,			&buffer->stx_gid	) ||
>> +	    __put_user(stat->attributes,	&buffer->stx_attributes	) ||
>> +	    __put_user(stat->blksize,		&buffer->stx_blksize	) ||
>> +	    __put_user(MAJOR(stat->rdev),	&buffer->stx_rdev_major	) ||
>> +	    __put_user(MINOR(stat->rdev),	&buffer->stx_rdev_minor	) ||
>> +	    __put_user(MAJOR(stat->dev),	&buffer->stx_dev_major	) ||
>> +	    __put_user(MINOR(stat->dev),	&buffer->stx_dev_minor	) ||
>> +	    __put_timestamp(stat->atime,	&buffer->stx_atime	) ||
>> +	    __put_timestamp(stat->btime,	&buffer->stx_btime	) ||
>> +	    __put_timestamp(stat->ctime,	&buffer->stx_ctime	) ||
>> +	    __put_timestamp(stat->mtime,	&buffer->stx_mtime	) ||
>> +	    __put_user(stat->ino,		&buffer->stx_ino	) ||
>> +	    __put_user(stat->size,		&buffer->stx_size	) ||
>> +	    __put_user(stat->blocks,		&buffer->stx_blocks	) ||
>> +	    __put_user(stat->version,		&buffer->stx_version	) ||
>> +	    __clear_user(&buffer->__spare1, sizeof(buffer->__spare1)))
>> +		return -EFAULT;
>> +
>> +	return 0;
>> +}
>> +
>> +/**
>> + * sys_statx - System call to get enhanced stats
>> + * @dfd: Base directory to pathwalk from *or* fd to stat.
>> + * @filename: File to stat *or* NULL.
>> + * @flags: AT_* flags to control pathwalk.
>> + * @mask: Parts of statx struct actually required.
>> + * @buffer: Result buffer.
>> + *
>> + * Note that if filename is NULL, then it does the equivalent of fstat() using
>> + * dfd to indicate the file of interest.
>> + */
>> +SYSCALL_DEFINE5(statx,
>> +		int, dfd, const char __user *, filename, unsigned, flags,
>> +		unsigned int, mask,
>> +		struct statx __user *, buffer)
>> +{
>> +	struct kstat stat;
>> +	int error;
>> +
>> +	if (!access_ok(VERIFY_WRITE, buffer, sizeof(*buffer)))
>> +		return -EFAULT;
>> +
>> +	memset(&stat, 0, sizeof(stat));
>> +	stat.query_flags = flags;
>> +	stat.request_mask = mask & STATX_ALL;
>> +
>> +	if (filename)
>> +		error = vfs_statx(dfd, filename, flags, &stat);
>> +	else
>> +		error = vfs_fstatx(dfd, &stat);
>> +	if (error)
>> +		return error;
>> +	return statx_set_result(&stat, buffer);
>> +}
>> +
>> /* Caller is here responsible for sufficient locking (ie. inode->i_lock) */
>> void __inode_add_bytes(struct inode *inode, loff_t bytes)
>> {
>> diff --git a/include/linux/fs.h b/include/linux/fs.h
>> index 16d2b6e874d6..f153199566b4 100644
>> --- a/include/linux/fs.h
>> +++ b/include/linux/fs.h
>> @@ -2916,8 +2916,9 @@ extern const struct inode_operations page_symlink_inode_operations;
>> extern void kfree_link(void *);
>> extern int generic_readlink(struct dentry *, char __user *, int);
>> extern void generic_fillattr(struct inode *, struct kstat *);
>> -int vfs_getattr_nosec(struct path *path, struct kstat *stat);
>> +extern int vfs_xgetattr_nosec(struct path *path, struct kstat *stat);
>> extern int vfs_getattr(struct path *, struct kstat *);
>> +extern int vfs_xgetattr(struct path *, struct kstat *);
>> void __inode_add_bytes(struct inode *inode, loff_t bytes);
>> void inode_add_bytes(struct inode *inode, loff_t bytes);
>> void __inode_sub_bytes(struct inode *inode, loff_t bytes);
>> @@ -2935,6 +2936,8 @@ extern int vfs_lstat(const char __user *, struct kstat *);
>> extern int vfs_fstat(unsigned int, struct kstat *);
>> extern int vfs_fstatat(int , const char __user *, struct kstat *, int);
>> extern const char *vfs_get_link(struct dentry *, struct delayed_call *);
>> +extern int vfs_xstat(int, const char __user *, int, struct kstat *);
>> +extern int vfs_xfstat(unsigned int, struct kstat *);
>> 
>> extern int __generic_block_fiemap(struct inode *inode,
>> 				  struct fiemap_extent_info *fieinfo,
>> diff --git a/include/linux/stat.h b/include/linux/stat.h
>> index 075cb0c7eb2a..cf25bb5cf754 100644
>> --- a/include/linux/stat.h
>> +++ b/include/linux/stat.h
>> @@ -19,19 +19,26 @@
>> #include <linux/uidgid.h>
>> 
>> struct kstat {
>> -	u64		ino;
>> -	dev_t		dev;
>> +	u32		query_flags;	/* Operational flags */
>> +#define KSTAT_QUERY_FLAGS (AT_STATX_FORCE_SYNC | AT_STATX_DONT_SYNC)
>> +	u32		request_mask;	/* What fields the user asked for */
>> +	u32		result_mask;	/* What fields the user got */
>> 	umode_t		mode;
>> 	unsigned int	nlink;
>> +	uint32_t	blksize;	/* Preferred I/O size */
>> +	u64		attributes;
>> +	u64		ino;
>> +	dev_t		dev;
>> +	dev_t		rdev;
>> 	kuid_t		uid;
>> 	kgid_t		gid;
>> -	dev_t		rdev;
>> 	loff_t		size;
>> -	struct timespec  atime;
>> +	struct timespec	atime;
>> 	struct timespec	mtime;
>> 	struct timespec	ctime;
>> -	unsigned long	blksize;
>> -	unsigned long long	blocks;
>> +	struct timespec	btime;			/* File creation time */
>> +	u64		blocks;
>> +	u64		version;		/* Data version */
>> };
>> 
>> #endif
>> diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h
>> index 91a740f6b884..980c3c9b06f8 100644
>> --- a/include/linux/syscalls.h
>> +++ b/include/linux/syscalls.h
>> @@ -48,6 +48,7 @@ struct stat;
>> struct stat64;
>> struct statfs;
>> struct statfs64;
>> +struct statx;
>> struct __sysctl_args;
>> struct sysinfo;
>> struct timespec;
>> @@ -902,5 +903,7 @@ asmlinkage long sys_pkey_mprotect(unsigned long start, size_t len,
>> 				  unsigned long prot, int pkey);
>> asmlinkage long sys_pkey_alloc(unsigned long flags, unsigned long init_val);
>> asmlinkage long sys_pkey_free(int pkey);
>> +asmlinkage long sys_statx(int dfd, const char __user *path, unsigned flags,
>> +			  unsigned mask, struct statx __user *buffer);
>> 
>> #endif
>> diff --git a/include/uapi/linux/fcntl.h b/include/uapi/linux/fcntl.h
>> index beed138bd359..c49cb6edaafa 100644
>> --- a/include/uapi/linux/fcntl.h
>> +++ b/include/uapi/linux/fcntl.h
>> @@ -62,6 +62,8 @@
>> #define AT_SYMLINK_FOLLOW	0x400   /* Follow symbolic links.  */
>> #define AT_NO_AUTOMOUNT		0x800	/* Suppress terminal automount traversal */
>> #define AT_EMPTY_PATH		0x1000	/* Allow empty relative pathname */
>> +#define AT_STATX_FORCE_SYNC	0x2000	/* Force the attributes to be sync'd with the server */
>> +#define AT_STATX_DONT_SYNC	0x4000	/* Don't sync attributes with the server */
>> 
>> 
>> #endif /* _UAPI_LINUX_FCNTL_H */
>> diff --git a/include/uapi/linux/stat.h b/include/uapi/linux/stat.h
>> index 7fec7e36d921..32ea14c1c960 100644
>> --- a/include/uapi/linux/stat.h
>> +++ b/include/uapi/linux/stat.h
>> @@ -1,6 +1,7 @@
>> #ifndef _UAPI_LINUX_STAT_H
>> #define _UAPI_LINUX_STAT_H
>> 
>> +#include <linux/types.h>
>> 
>> #if defined(__KERNEL__) || !defined(__GLIBC__) || (__GLIBC__ < 2)
>> 
>> @@ -41,5 +42,128 @@
>> 
>> #endif
>> 
>> +/*
>> + * Structures for the extended file attribute retrieval system call
>> + * (statx()).
>> + *
>> + * The caller passes a mask of what they're specifically interested in as a
>> + * parameter to statx().  What statx() actually got will be indicated in
>> + * st_mask upon return.
>> + *
>> + * For each bit in the mask argument:
>> + *
>> + * - if the datum is not supported:
>> + *
>> + *   - the bit will be cleared, and
>> + *
>> + *   - the datum will be set to an appropriate fabricated value if one is
>> + *     available (eg. CIFS can take a default uid and gid), otherwise
>> + *
>> + *   - the field will be cleared;
>> + *
>> + * - otherwise, if explicitly requested:
>> + *
>> + *   - the datum will be synchronised to the server if AT_STATX_FORCE_SYNC is
>> + *     set or if the datum is considered out of date, and
>> + *
>> + *   - the field will be filled in and the bit will be set;
>> + *
>> + * - otherwise, if not requested, but available in approximate form without any
>> + *   effort, it will be filled in anyway, and the bit will be set upon return
>> + *   (it might not be up to date, however, and no attempt will be made to
>> + *   synchronise the internal state first);
>> + *
>> + * - otherwise the field and the bit will be cleared before returning.
>> + *
>> + * Items in STATX_BASIC_STATS may be marked unavailable on return, but they
>> + * will have values installed for compatibility purposes so that stat() and
>> + * co. can be emulated in userspace.
>> + */
>> +struct statx {
>> +	/* 0x00 */
>> +	__u32	stx_mask;	/* What results were written [uncond] */
>> +	__u32	stx_blksize;	/* Preferred general I/O size [uncond] */
>> +	__u64	stx_attributes;	/* Flags conveying information about the file [uncond] */
>> +	/* 0x10 */
>> +	__u32	stx_nlink;	/* Number of hard links */
>> +	__u32	stx_uid;	/* User ID of owner */
>> +	__u32	stx_gid;	/* Group ID of owner */
>> +	__u16	stx_mode;	/* File mode */
>> +	__u16	__spare0[1];
>> +	/* 0x20 */
>> +	__u64	stx_ino;	/* Inode number */
>> +	__u64	stx_size;	/* File size */
>> +	__u64	stx_blocks;	/* Number of 512-byte blocks allocated */
>> +	__u64	stx_version;	/* Data version number */
>> +	/* 0x40 */
>> +	__s64	stx_atime_s;	/* Last access time */
>> +	__s64	stx_btime_s;	/* File creation time */
>> +	__s64	stx_ctime_s;	/* Last attribute change time */
>> +	__s64	stx_mtime_s;	/* Last data modification time */
>> +	/* 0x60 */
>> +	__s32	stx_atime_ns;	/* Last access time (ns part) */
>> +	__s32	stx_btime_ns;	/* File creation time (ns part) */
>> +	__s32	stx_ctime_ns;	/* Last attribute change time (ns part) */
>> +	__s32	stx_mtime_ns;	/* Last data modification time (ns part) */
>> +	/* 0x70 */
>> +	__u32	stx_rdev_major;	/* Device ID of special file [if bdev/cdev] */
>> +	__u32	stx_rdev_minor;
>> +	__u32	stx_dev_major;	/* ID of device containing file [uncond] */
>> +	__u32	stx_dev_minor;
>> +	/* 0x80 */
>> +	__u64	__spare1[16];	/* Spare space for future expansion */
>> +	/* 0x100 */
>> +};
>> +
>> +/*
>> + * Flags to be stx_mask
>> + *
>> + * Query request/result mask for statx() and struct statx::stx_mask.
>> + *
>> + * These bits should be set in the mask argument of statx() to request
>> + * particular items when calling statx().
>> + */
>> +#define STATX_TYPE		0x00000001U	/* Want/got stx_mode & S_IFMT */
>> +#define STATX_MODE		0x00000002U	/* Want/got stx_mode & ~S_IFMT */
>> +#define STATX_NLINK		0x00000004U	/* Want/got stx_nlink */
>> +#define STATX_UID		0x00000008U	/* Want/got stx_uid */
>> +#define STATX_GID		0x00000010U	/* Want/got stx_gid */
>> +#define STATX_ATIME		0x00000020U	/* Want/got stx_atime */
>> +#define STATX_MTIME		0x00000040U	/* Want/got stx_mtime */
>> +#define STATX_CTIME		0x00000080U	/* Want/got stx_ctime */
>> +#define STATX_INO		0x00000100U	/* Want/got stx_ino */
>> +#define STATX_SIZE		0x00000200U	/* Want/got stx_size */
>> +#define STATX_BLOCKS		0x00000400U	/* Want/got stx_blocks */
>> +#define STATX_BASIC_STATS	0x000007ffU	/* The stuff in the normal stat struct */
>> +#define STATX_BTIME		0x00000800U	/* Want/got stx_btime */
>> +#define STATX_VERSION		0x00001000U	/* Want/got stx_version */
>> +#define STATX_ALL		0x00001fffU	/* All currently supported flags */
>> +
>> +/*
>> + * Attributes to be found in stx_attributes
>> + *
>> + * These give information about the features or the state of a file that might
>> + * be of use to ordinary userspace programs such as GUIs or ls rather than
>> + * specialised tools.
>> + *
>> + * Note that the flags marked [I] correspond to generic FS_IOC_FLAGS
>> + * semantically.  Where possible, the numerical value is picked to correspond
>> + * also.
>> + */
>> +#define STATX_ATTR_COMPRESSED		0x00000004 /* [I] File is compressed by the fs */
>> +#define STATX_ATTR_IMMUTABLE		0x00000010 /* [I] File is marked immutable */
>> +#define STATX_ATTR_APPEND		0x00000020 /* [I] File is append-only */
>> +#define STATX_ATTR_NODUMP		0x00000040 /* [I] File is not to be dumped */
>> +#define STATX_ATTR_NONUNIX_OWNERSHIP	0x00000100 /* File has non-Unix ownership details */
>> +#define STATX_ATTR_HAS_ACL		0x00000200 /* File has an ACL */
>> +#define STATX_ATTR_ENCRYPTED		0x00000800 /* [I] File requires key to decrypt in fs */
>> +#define STATX_ATTR_FS_IOC_FLAGS		0x00000874 /* Attrs corresponding to FS_*_FL flags */
>> +
>> +#define STATX_ATTR_KERNEL_API		0x00001000 /* File is kernel API (eg: procfs/sysfs) */
>> +#define STATX_ATTR_REMOTE		0x00002000 /* File is remote and needs network */
>> +#define STATX_ATTR_FABRICATED		0x00004000 /* File was made up by fs and is transient */
>> +#define STATX_ATTR_AUTOMOUNT		0x00008000 /* Dir: Automount trigger */
>> +#define STATX_ATTR_UNLISTED_DENTS	0x00010000 /* Dir: Lookup may find files getdents doesn't */
>> +
>> 
>> #endif /* _UAPI_LINUX_STAT_H */
>> diff --git a/samples/Kconfig b/samples/Kconfig
>> index a6d2a43bbf2e..94a7488f14ae 100644
>> --- a/samples/Kconfig
>> +++ b/samples/Kconfig
>> @@ -105,4 +105,9 @@ config SAMPLE_BLACKFIN_GPTIMERS
>> 	help
>> 	  Build samples of blackfin gptimers sample module.
>> 
>> +config SAMPLE_STATX
>> +	bool "Build example extended-stat using code"
>> +	help
>> +	  Build example userspace program to use the new extended-stat syscall.
>> +
>> endif # SAMPLES
>> diff --git a/samples/Makefile b/samples/Makefile
>> index e17d66d77f09..8eeb15e13413 100644
>> --- a/samples/Makefile
>> +++ b/samples/Makefile
>> @@ -2,4 +2,5 @@
>> 
>> obj-$(CONFIG_SAMPLES)	+= kobject/ kprobes/ trace_events/ livepatch/ \
>> 			   hw_breakpoint/ kfifo/ kdb/ hidraw/ rpmsg/ seccomp/ \
>> -			   configfs/ connector/ v4l/ trace_printk/ blackfin/
>> +			   configfs/ connector/ v4l/ trace_printk/ blackfin/ \
>> +			   statx/
>> diff --git a/samples/statx/Makefile b/samples/statx/Makefile
>> new file mode 100644
>> index 000000000000..1f80a3d8cf45
>> --- /dev/null
>> +++ b/samples/statx/Makefile
>> @@ -0,0 +1,10 @@
>> +# kbuild trick to avoid linker error. Can be omitted if a module is built.
>> +obj- := dummy.o
>> +
>> +# List of programs to build
>> +hostprogs-$(CONFIG_SAMPLE_STATX) := test-statx
>> +
>> +# Tell kbuild to always build the programs
>> +always := $(hostprogs-y)
>> +
>> +HOSTCFLAGS_test-statx.o += -I$(objtree)/usr/include
>> diff --git a/samples/statx/test-statx.c b/samples/statx/test-statx.c
>> new file mode 100644
>> index 000000000000..2419b33fc15d
>> --- /dev/null
>> +++ b/samples/statx/test-statx.c
>> @@ -0,0 +1,248 @@
>> +/* Test the statx() system call
>> + *
>> + * Copyright (C) 2015 Red Hat, Inc. All Rights Reserved.
>> + * Written by David Howells (dhowells@redhat.com)
>> + *
>> + * This program is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU General Public Licence
>> + * as published by the Free Software Foundation; either version
>> + * 2 of the Licence, or (at your option) any later version.
>> + */
>> +
>> +#define _GNU_SOURCE
>> +#define _ATFILE_SOURCE
>> +#include <stdio.h>
>> +#include <stdlib.h>
>> +#include <string.h>
>> +#include <unistd.h>
>> +#include <ctype.h>
>> +#include <errno.h>
>> +#include <time.h>
>> +#include <sys/syscall.h>
>> +#include <sys/types.h>
>> +#include <linux/stat.h>
>> +#include <linux/fcntl.h>
>> +#include <sys/stat.h>
>> +
>> +#define AT_STATX_FORCE_SYNC	0x2000
>> +#define AT_STATX_DONT_SYNC	0x4000
>> +
>> +static __attribute__((unused))
>> +ssize_t statx(int dfd, const char *filename, unsigned flags,
>> +	      unsigned int mask, struct statx *buffer)
>> +{
>> +	return syscall(__NR_statx, dfd, filename, flags, mask, buffer);
>> +}
>> +
>> +static void print_time(const char *field, __s64 tv_sec, __s32 tv_nsec)
>> +{
>> +	struct tm tm;
>> +	time_t tim;
>> +	char buffer[100];
>> +	int len;
>> +
>> +	tim = tv_sec;
>> +	if (!localtime_r(&tim, &tm)) {
>> +		perror("localtime_r");
>> +		exit(1);
>> +	}
>> +	len = strftime(buffer, 100, "%F %T", &tm);
>> +	if (len == 0) {
>> +		perror("strftime");
>> +		exit(1);
>> +	}
>> +	printf("%s", field);
>> +	fwrite(buffer, 1, len, stdout);
>> +	printf(".%09u", tv_nsec);
>> +	len = strftime(buffer, 100, "%z", &tm);
>> +	if (len == 0) {
>> +		perror("strftime2");
>> +		exit(1);
>> +	}
>> +	fwrite(buffer, 1, len, stdout);
>> +	printf("\n");
>> +}
>> +
>> +static void dump_statx(struct statx *stx)
>> +{
>> +	char buffer[256], ft = '?';
>> +
>> +	printf("results=%x\n", stx->stx_mask);
>> +
>> +	printf(" ");
>> +	if (stx->stx_mask & STATX_SIZE)
>> +		printf(" Size: %-15llu", (unsigned long long)stx->stx_size);
>> +	if (stx->stx_mask & STATX_BLOCKS)
>> +		printf(" Blocks: %-10llu", (unsigned long long)stx->stx_blocks);
>> +	printf(" IO Block: %-6llu ", (unsigned long long)stx->stx_blksize);
>> +	if (stx->stx_mask & STATX_MODE) {
>> +		switch (stx->stx_mode & S_IFMT) {
>> +		case S_IFIFO:	printf(" FIFO\n");			ft = 'p'; break;
>> +		case S_IFCHR:	printf(" character special file\n");	ft = 'c'; break;
>> +		case S_IFDIR:	printf(" directory\n");			ft = 'd'; break;
>> +		case S_IFBLK:	printf(" block special file\n");	ft = 'b'; break;
>> +		case S_IFREG:	printf(" regular file\n");		ft = '-'; break;
>> +		case S_IFLNK:	printf(" symbolic link\n");		ft = 'l'; break;
>> +		case S_IFSOCK:	printf(" socket\n");			ft = 's'; break;
>> +		default:
>> +			printf("unknown type (%o)\n", stx->stx_mode & S_IFMT);
>> +			break;
>> +		}
>> +	}
>> +
>> +	sprintf(buffer, "%02x:%02x", stx->stx_dev_major, stx->stx_dev_minor);
>> +	printf("Device: %-15s", buffer);
>> +	if (stx->stx_mask & STATX_INO)
>> +		printf(" Inode: %-11llu", (unsigned long long) stx->stx_ino);
>> +	if (stx->stx_mask & STATX_SIZE)
>> +		printf(" Links: %-5u", stx->stx_nlink);
>> +	switch (stx->stx_mask & STATX_MODE) {
>> +	case S_IFBLK:
>> +	case S_IFCHR:
>> +		printf(" Device type: %u,%u", stx->stx_rdev_major, stx->stx_rdev_minor);
>> +		break;
>> +	}
>> +	printf("\n");
>> +
>> +	if (stx->stx_mask & STATX_MODE)
>> +		printf("Access: (%04o/%c%c%c%c%c%c%c%c%c%c)  ",
>> +		       stx->stx_mode & 07777,
>> +		       ft,
>> +		       stx->stx_mode & S_IRUSR ? 'r' : '-',
>> +		       stx->stx_mode & S_IWUSR ? 'w' : '-',
>> +		       stx->stx_mode & S_IXUSR ? 'x' : '-',
>> +		       stx->stx_mode & S_IRGRP ? 'r' : '-',
>> +		       stx->stx_mode & S_IWGRP ? 'w' : '-',
>> +		       stx->stx_mode & S_IXGRP ? 'x' : '-',
>> +		       stx->stx_mode & S_IROTH ? 'r' : '-',
>> +		       stx->stx_mode & S_IWOTH ? 'w' : '-',
>> +		       stx->stx_mode & S_IXOTH ? 'x' : '-');
>> +	if (stx->stx_mask & STATX_UID)
>> +		printf("Uid: %5d   ", stx->stx_uid);
>> +	if (stx->stx_mask & STATX_GID)
>> +		printf("Gid: %5d\n", stx->stx_gid);
>> +
>> +	if (stx->stx_mask & STATX_ATIME)
>> +		print_time("Access: ", stx->stx_atime_s, stx->stx_atime_ns);
>> +	if (stx->stx_mask & STATX_MTIME)
>> +		print_time("Modify: ", stx->stx_mtime_s, stx->stx_mtime_ns);
>> +	if (stx->stx_mask & STATX_CTIME)
>> +		print_time("Change: ", stx->stx_ctime_s, stx->stx_ctime_ns);
>> +	if (stx->stx_mask & STATX_BTIME)
>> +		print_time(" Birth: ", stx->stx_btime_s, stx->stx_btime_ns);
>> +
>> +	if (stx->stx_mask & STATX_VERSION)
>> +		printf("Data version: %llxh\n",
>> +		       (unsigned long long)stx->stx_version);
>> +
>> +	if (stx->stx_attributes) {
>> +		unsigned char bits;
>> +		int loop, byte;
>> +
>> +		static char attr_representation[64 + 1] =
>> +			/* STATX_ATTR_ flags: */
>> +			"????????"	/* 63-56 */
>> +			"????????"	/* 55-48 */
>> +			"????????"	/* 47-40 */
>> +			"????????"	/* 39-32 */
>> +			"????????"	/* 31-24	0x00000000-ff000000 */
>> +			"???????u"	/* 23-16	0x00000000-00ff0000 */
>> +			"mfrke?AU"	/* 15- 8	0x00000000-0000ff00 */
>> +			"?dai?c??"	/*  7- 0	0x00000000-000000ff */
>> +			;
>> +
>> +		printf("Attributes: %016llx (", stx->stx_attributes);
>> +		for (byte = 64 - 8; byte >= 0; byte -= 8) {
>> +			bits = stx->stx_attributes >> byte;
>> +			for (loop = 7; loop >= 0; loop--) {
>> +				int bit = byte + loop;
>> +
>> +				if (bits & 0x80)
>> +					putchar(attr_representation[63 - bit]);
>> +				else
>> +					putchar('-');
>> +				bits <<= 1;
>> +			}
>> +			if (byte)
>> +				putchar(' ');
>> +		}
>> +		printf(")\n");
>> +	}
>> +
>> +	printf("IO-blocksize: blksize=%u\n", stx->stx_blksize);
>> +}
>> +
>> +static void dump_hex(unsigned long long *data, int from, int to)
>> +{
>> +	unsigned offset, print_offset = 1, col = 0;
>> +
>> +	from /= 8;
>> +	to = (to + 7) / 8;
>> +
>> +	for (offset = from; offset < to; offset++) {
>> +		if (print_offset) {
>> +			printf("%04x: ", offset * 8);
>> +			print_offset = 0;
>> +		}
>> +		printf("%016llx", data[offset]);
>> +		col++;
>> +		if ((col & 3) == 0) {
>> +			printf("\n");
>> +			print_offset = 1;
>> +		} else {
>> +			printf(" ");
>> +		}
>> +	}
>> +
>> +	if (!print_offset)
>> +		printf("\n");
>> +}
>> +
>> +int main(int argc, char **argv)
>> +{
>> +	struct statx stx;
>> +	int ret, raw = 0, atflag = AT_SYMLINK_NOFOLLOW;
>> +
>> +	unsigned int mask = STATX_ALL;
>> +
>> +	for (argv++; *argv; argv++) {
>> +		if (strcmp(*argv, "-F") == 0) {
>> +			atflag |= AT_STATX_FORCE_SYNC;
>> +			continue;
>> +		}
>> +		if (strcmp(*argv, "-D") == 0) {
>> +			atflag |= AT_STATX_DONT_SYNC;
>> +			continue;
>> +		}
>> +		if (strcmp(*argv, "-L") == 0) {
>> +			atflag &= ~AT_SYMLINK_NOFOLLOW;
>> +			continue;
>> +		}
>> +		if (strcmp(*argv, "-O") == 0) {
>> +			mask &= ~STATX_BASIC_STATS;
>> +			continue;
>> +		}
>> +		if (strcmp(*argv, "-A") == 0) {
>> +			atflag |= AT_NO_AUTOMOUNT;
>> +			continue;
>> +		}
>> +		if (strcmp(*argv, "-R") == 0) {
>> +			raw = 1;
>> +			continue;
>> +		}
>> +
>> +		memset(&stx, 0xbf, sizeof(stx));
>> +		ret = statx(AT_FDCWD, *argv, atflag, mask, &stx);
>> +		printf("statx(%s) = %d\n", *argv, ret);
>> +		if (ret < 0) {
>> +			perror(*argv);
>> +			exit(1);
>> +		}
>> +
>> +		if (raw)
>> +			dump_hex((unsigned long long *)&stx, 0, sizeof(stx));
>> +
>> +		dump_statx(&stx);
>> +	}
>> +	return 0;
>> +}
>> 
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> --
> Jeff Layton <jlayton@redhat.com>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


Cheers, Andreas






[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available
  2016-11-17 23:40   ` Dave Chinner
@ 2016-11-18  3:28     ` Andreas Dilger
  2016-11-18 22:07       ` Dave Chinner
  2016-11-18 22:54       ` David Howells
  2016-11-18  9:53     ` David Howells
  1 sibling, 2 replies; 52+ messages in thread
From: Andreas Dilger @ 2016-11-18  3:28 UTC (permalink / raw)
  To: Dave Chinner; +Cc: David Howells, linux-fsdevel, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 9198 bytes --]

On Nov 17, 2016, at 4:40 PM, Dave Chinner <david@fromorbit.com> wrote:
> 
> On Thu, Nov 17, 2016 at 01:35:03PM +0000, David Howells wrote:
>> Add a system call to make extended file information available, including
>> file creation, data version and some attribute flags where available
>> through the underlying filesystem.
>> 
>> 
>> ========
>> OVERVIEW
>> ========
>> 
>> The idea was initially proposed as a set of xattrs that could be retrieved
>> with getxattr(), but the general preferance proved to be for a new syscall
>> with an extended stat structure.
>> 
>> This has a number of uses:
>> 
> ....
>> (5) Data version number: Could be used by userspace NFS servers [Aneesh
>>     Kumar].
>> 
>>     Can also be used to modify fill_post_wcc() in NFSD which retrieves
>>     i_version directly, but has just called vfs_getattr().  It could get
>>     it from the kstat struct if it used vfs_xgetattr() instead.
> 
> This needs a much clearer name that stx_version as "version" is
> entirely ambiguous. e.g. Inodes have internal version numbers to
> disambiguate life cycles. and there are versioning filesystems
> which have multiple versions of the same file.
> 
> So if stx_version this is intended to export the internal filesystem
> inode change counter (i.e. inode->i_version) then lets call it that:
> stx_modification_count. It's clear and unambiguous as to what it
> represents, especially as this counter is more than just a "data
> modification" counter - inode metadata modifications will also
> cause it to change...

Honestly, I don't think "modification count" is necessarily more clear
than "version".  This value isn't necessarily a counter incremented
to hold the number of times the inode was modified, but is used by NFS
only to determine whether the inode has been modified from one access to
the next.  It may not be incremented sequentially for each inode, but
rather be a global value across all inodes in the filesystem.  It is
much more important to clearly document what this version field means.
Maybe "stx_modification_version", but I'm fine with "version" as well,
since this is what the field is named in the kernel.

>> (13) FS_IOC_GETFLAGS value.  These could be translated to BSD's st_flags.
>>     Note that the Linux IOC flags are a mess and filesystems such as Ext4
>>     define flags that aren't in linux/fs.h, so translation in the kernel
>>     may be a necessity (or, possibly, we provide the filesystem type too).
> 
> And we now also have FS_IOC_FSGETXATTR that extends the flags
> and information userspace can get from filesystems. It makes little
> sense to now add xstat() and not add everything this interface
> also exports...

The number of flags available will always be a moving target.  Better
to get the core functionality landed, and then add in new flags in a
later patch, otherwise this patch will never be landed.

>> The defined bits in request_mask and stx_mask are:
>> 
>> 	STATX_TYPE		Want/got stx_mode & S_IFMT
>> 	STATX_MODE		Want/got stx_mode & ~S_IFMT
>> 	STATX_NLINK		Want/got stx_nlink
>> 	STATX_UID		Want/got stx_uid
>> 	STATX_GID		Want/got stx_gid
>> 	STATX_ATIME		Want/got stx_atime{,_ns}
>> 	STATX_MTIME		Want/got stx_mtime{,_ns}
>> 	STATX_CTIME		Want/got stx_ctime{,_ns}
>> 	STATX_INO		Want/got stx_ino
>> 	STATX_SIZE		Want/got stx_size
>> 	STATX_BLOCKS		Want/got stx_blocks
>> 	STATX_BASIC_STATS	[The stuff in the normal stat struct]
>> 	STATX_BTIME		Want/got stx_btime{,_ns}
>> 	STATX_VERSION		Want/got stx_version
>> 	STATX_ALL		[All currently available stuff]
> 
> What happens when an application uses STATX_ALL from a future kernel
> that defines more flags than are initially supported, and that
> application then is run on a kernel that onyl supports the initial
> fields?

Fields that are unknown by the current kernel/filesystem will not be set,
and this is reflected in the flags that are returned to userspace.

The minimum required flags are the intersection of the requested flags
from userspace and the flags known by the kernel/filesystem.  It is
possible for the filesystem to optionally return extra flags/fields if
they are free to provide, but it should always return the requested
flags *if* it knows what those flags mean.

>> stx_btime is the file creation time; stx_version is the data version
>> number (i_version); stx_mask is a bitmask indicating the data provided;
>> and __spares*[] are where as-yet undefined fields can be placed.
>> 
>> Time fields are split into separate seconds and nanoseconds fields to make
>> packing easier and the granularities can be queried with the filesystem
>> info system call.  Note that times will be negative if before 1970; in
>> such a case, the nanosecond fields will also be negative if not zero.
> 
> So what happens in ten years time when we want to support
> femptosecond resolution in the timestamp interface? We've got to
> change everything to 64 bit? Shouldn't we just make everything
> timestamp related 64 bit?

Is this a serious request?  Are we going to need to multiply everything
by 10e9 to convert to/from nanoseconds for the next 10 years on the off
chance that we have timestamps more accurate than this in the future?
We could just as easily add extra 32-bit fields in the future to hold
the fraction of nanoseconds if we ever actually need this.  Given that
we've totally bailed on keeping accurate atimes below a day, I'm not
really worried about needing this.

>> The bits defined in the stx_attributes field convey information about a
>> file, how it is accessed, where it is and what it does.  The following
>> attributes map to FS_*_FL flags and are the same numerical value:
> 
> Please isolate the new interface flags completely from the FS_*_FL
> values. We should not repeat the mistake of tying values derived
> from filesystem specific on-disk values to a user interface.

Using the existing FS_*_FL flags as initial values is not worse than
starting with any other arbitrary values for the flags.

>> 	STATX_ATTR_COMPRESSED		File is compressed by the fs
>> 	STATX_ATTR_IMMUTABLE		File is marked immutable
>> 	STATX_ATTR_APPEND		File is append-only
>> 	STATX_ATTR_NODUMP		File is not to be dumped
>> 	STATX_ATTR_ENCRYPTED		File requires key to decrypt in fs
>> 
>> The supported flags are listed by:
>> 
>> 	STATX_ATTR_FS_IOC_FLAGS
> 
> Again, we have many more common and extended flags than this.
> NOATIME and SYNC are two that immediately come to mind as generic
> flags that should be in this...

Sure, and they can be added incrementally in a later patch.  I'm not
sure why NOATIME and SYNC are missing, and I'm not against adding them,
but it is equally likely that they were removed in a previous round of
bikeshedding to avoid some real or perceived issue, so that this patch
can finally land rather than being in limbo for another 5 years.

>> [Are any other IOC flags of sufficient general interest to be exposed
>> through this interface?]
>> 
>> New flags include:
>> 
>> 	STATX_ATTR_NONUNIX_OWNERSHIP	File doesn't have Unixy ownership
>> 	STATX_ATTR_HAS_ACL		File has an ACL
> 
> So statx will require us to do ACL lookups? i.e. instead of just
> reading the inode to get the information, we'll also have to do
> extended attribute lookups? That's potentially very expensive if
> the extended attribute is not stored in the inode....

No, there is no requirement to return anything that the caller didn't
ask for.  Only fields that are explicitly requested need to be returned,
and others can optionally be returned if it is easy for the filesystem
to do so.

>> 	STATX_ATTR_KERNEL_API		File is kernel API (eg: procfs/sysfs)
>> 	STATX_ATTR_REMOTE		File is remote and needs network
>> 	STATX_ATTR_FABRICATED		File was made up by fs
> 
> Every file is fabricated by a filesystem :P
> 
> Perhaps you're wanting "virtual file" because it is has no physical
> presence?
> 
>> Fields in struct statx come in a number of classes:
>> 
>> (0) stx_dev_*, stx_blksize.
>> 
>>     These are local system information and are always available.
> 
> What does stx_blksize actually mean? It's completely ambiguous in
> stat() because we don't actually report the physical block size
> here - we report the "minimum unit of efficient IO" that we expect
> applications to use. Please define :P
> 
> 
>> =======
>> TESTING
>> =======
>> 
>> The following test program can be used to test the statx system call:
>> 
>> 	samples/statx/test-statx.c
>> 
>> Just compile and run, passing it paths to the files you want to examine.
>> The file is built automatically if CONFIG_SAMPLES is enabled.
> 
> Can we get xfstests written to exercise and validate all this
> functionality, please? I'd suggest that adding xfs_io support for
> the statx syscall would be far more useful for xfstests than a
> standalone  test program, too. We already have equivalent stat()
> functionality in xfs_io and that's used quite a bit in xfstests....
> 
> Cheers,
> 
> Dave.
> --
> Dave Chinner
> david@fromorbit.com
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


Cheers, Andreas






[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [PATCH 2/4] statx: Ext4: Return enhanced file attributes
  2016-11-17 13:35 ` [PATCH 2/4] statx: Ext4: Return enhanced file attributes David Howells
@ 2016-11-18  3:30   ` Andreas Dilger
  0 siblings, 0 replies; 52+ messages in thread
From: Andreas Dilger @ 2016-11-18  3:30 UTC (permalink / raw)
  To: David Howells; +Cc: linux-fsdevel, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 6168 bytes --]

On Nov 17, 2016, at 6:35 AM, David Howells <dhowells@redhat.com> wrote:
> 
> Return enhanced file attributes from the Ext4 filesystem.  This includes
> the following:
> 
> (1) The inode creation time (i_crtime) as stx_btime, setting STATX_BTIME.
> 
> (2) The inode i_version as stx_version if a file with I_VERSION set or a
>     directory, setting STATX_VERSION.
> 
> (3) Certain FS_xxx_FL flags are copied to stx_attribute flags.
> 
> 
> This requires that all ext4 inodes have a getattr call, not just some of
> them, so to this end, split the ext4_getattr() function and only call part
> of it where appropriate.
> 
> Example output:
> 
> 	[root@andromeda ~]# touch foo
> 	[root@andromeda ~]# chattr +ai foo
> 	[root@andromeda ~]# /tmp/test-statx foo
> 	statx(foo) = 0
> 	results=fff
> 	  Size: 0               Blocks: 0          IO Block: 4096    regular file
> 	Device: 08:12           Inode: 2101950     Links: 1
> 	Access: (0644/-rw-r--r--)  Uid:     0   Gid:     0
> 	Access: 2016-02-11 17:08:29.031795451+0000
> 	Modify: 2016-02-11 17:08:29.031795451+0000
> 	Change: 2016-02-11 17:11:11.987790114+0000
> 	 Birth: 2016-02-11 17:08:29.031795451+0000
> 	Attributes: 0000000000000030 (-------- -------- -------- -------- -------- -------- -------- --ai----)
> 	IO-blocksize: blksize=4096
> 
> Signed-off-by: David Howells <dhowells@redhat.com>

Reviewed-by: Andreas Dilger <adilger@dilger.ca>

> ---
> 
> fs/ext4/ext4.h    |    2 ++
> fs/ext4/file.c    |    2 +-
> fs/ext4/inode.c   |   38 +++++++++++++++++++++++++++++++++++---
> fs/ext4/namei.c   |    2 ++
> fs/ext4/symlink.c |    2 ++
> 5 files changed, 42 insertions(+), 4 deletions(-)
> 
> diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
> index 282a51b07c57..f65e4a560c4c 100644
> --- a/fs/ext4/ext4.h
> +++ b/fs/ext4/ext4.h
> @@ -2485,6 +2485,8 @@ extern int  ext4_getattr(struct vfsmount *mnt, struct dentry *dentry,
> 				struct kstat *stat);
> extern void ext4_evict_inode(struct inode *);
> extern void ext4_clear_inode(struct inode *);
> +extern int  ext4_file_getattr(struct vfsmount *mnt, struct dentry *dentry,
> +			      struct kstat *stat);
> extern int  ext4_sync_inode(handle_t *, struct inode *);
> extern void ext4_dirty_inode(struct inode *, int);
> extern int ext4_change_inode_journal_flag(struct inode *, int);
> diff --git a/fs/ext4/file.c b/fs/ext4/file.c
> index 2a822d30e73f..20bab4b0d6fc 100644
> --- a/fs/ext4/file.c
> +++ b/fs/ext4/file.c
> @@ -705,7 +705,7 @@ const struct file_operations ext4_file_operations = {
> 
> const struct inode_operations ext4_file_inode_operations = {
> 	.setattr	= ext4_setattr,
> -	.getattr	= ext4_getattr,
> +	.getattr	= ext4_file_getattr,
> 	.listxattr	= ext4_listxattr,
> 	.get_acl	= ext4_get_acl,
> 	.set_acl	= ext4_set_acl,
> diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
> index 9c064727ed62..91a49cbc4c63 100644
> --- a/fs/ext4/inode.c
> +++ b/fs/ext4/inode.c
> @@ -5229,11 +5229,43 @@ int ext4_setattr(struct dentry *dentry, struct iattr *attr)
> int ext4_getattr(struct vfsmount *mnt, struct dentry *dentry,
> 		 struct kstat *stat)
> {
> -	struct inode *inode;
> -	unsigned long long delalloc_blocks;
> +	struct inode *inode = d_inode(dentry);
> +	struct ext4_inode *raw_inode;
> +	struct ext4_inode_info *ei = EXT4_I(inode);
> +	unsigned int flags;
> +
> +	if (EXT4_FITS_IN_INODE(raw_inode, ei, i_crtime)) {
> +		stat->result_mask |= STATX_BTIME;
> +		stat->btime.tv_sec = ei->i_crtime.tv_sec;
> +		stat->btime.tv_nsec = ei->i_crtime.tv_nsec;
> +	}
> +
> +	if (S_ISDIR(inode->i_mode) || IS_I_VERSION(inode)) {
> +		stat->result_mask |= STATX_VERSION;
> +		stat->version = inode->i_version;
> +	}
> +
> +	ext4_get_inode_flags(ei);
> +	flags = ei->i_flags & EXT4_FL_USER_VISIBLE;
> +	stat->attributes |= flags & (EXT4_IMMUTABLE_FL | EXT4_NODUMP_FL);
> +	if (flags & EXT4_APPEND_FL)
> +		stat->attributes |= STATX_ATTR_APPEND;
> +	if (flags & EXT4_COMPR_FL)
> +		stat->attributes |= STATX_ATTR_COMPRESSED;
> +	if (flags & EXT4_ENCRYPT_FL)
> +		stat->attributes |= STATX_ATTR_ENCRYPTED;
> 
> -	inode = d_inode(dentry);
> 	generic_fillattr(inode, stat);
> +	return 0;
> +}
> +
> +int ext4_file_getattr(struct vfsmount *mnt, struct dentry *dentry,
> +		      struct kstat *stat)
> +{
> +	struct inode *inode = dentry->d_inode;
> +	u64 delalloc_blocks;
> +
> +	ext4_getattr(mnt, dentry, stat);
> 
> 	/*
> 	 * If there is inline data in the inode, the inode will normally not
> diff --git a/fs/ext4/namei.c b/fs/ext4/namei.c
> index 104f8bfba718..e115281fb8c5 100644
> --- a/fs/ext4/namei.c
> +++ b/fs/ext4/namei.c
> @@ -3882,6 +3882,7 @@ const struct inode_operations ext4_dir_inode_operations = {
> 	.tmpfile	= ext4_tmpfile,
> 	.rename		= ext4_rename2,
> 	.setattr	= ext4_setattr,
> +	.getattr	= ext4_getattr,
> 	.listxattr	= ext4_listxattr,
> 	.get_acl	= ext4_get_acl,
> 	.set_acl	= ext4_set_acl,
> @@ -3890,6 +3891,7 @@ const struct inode_operations ext4_dir_inode_operations = {
> 
> const struct inode_operations ext4_special_inode_operations = {
> 	.setattr	= ext4_setattr,
> +	.getattr	= ext4_getattr,
> 	.listxattr	= ext4_listxattr,
> 	.get_acl	= ext4_get_acl,
> 	.set_acl	= ext4_set_acl,
> diff --git a/fs/ext4/symlink.c b/fs/ext4/symlink.c
> index 557b3b0d668c..209b833633e2 100644
> --- a/fs/ext4/symlink.c
> +++ b/fs/ext4/symlink.c
> @@ -93,6 +93,7 @@ const struct inode_operations ext4_symlink_inode_operations = {
> 	.readlink	= generic_readlink,
> 	.get_link	= page_get_link,
> 	.setattr	= ext4_setattr,
> +	.getattr	= ext4_getattr,
> 	.listxattr	= ext4_listxattr,
> };
> 
> @@ -100,5 +101,6 @@ const struct inode_operations ext4_fast_symlink_inode_operations = {
> 	.readlink	= generic_readlink,
> 	.get_link	= simple_get_link,
> 	.setattr	= ext4_setattr,
> +	.getattr	= ext4_getattr,
> 	.listxattr	= ext4_listxattr,
> };
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


Cheers, Andreas






[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [PATCH 4/4] statx: AFS: Return enhanced file attributes
  2016-11-17 13:35 ` [PATCH 4/4] statx: AFS: " David Howells
@ 2016-11-18  3:34   ` Andreas Dilger
  2016-11-18  8:47   ` David Howells
  1 sibling, 0 replies; 52+ messages in thread
From: Andreas Dilger @ 2016-11-18  3:34 UTC (permalink / raw)
  To: David Howells; +Cc: linux-fsdevel, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 3907 bytes --]

On Nov 17, 2016, at 6:35 AM, David Howells <dhowells@redhat.com> wrote:
> 
> Return enhanced file attributes from the AFS filesystem.  This includes the
> following:
> 
> (1) The data version number as st_version, setting STATX_VERSION.
> 
> (2) STATX_ATTR_AUTOMOUNT will be set on automount directories by virtue of
>     S_AUTOMOUNT being set on the inode.  These are referrals to other
>     volumes or other cells.
> 
> (3) STATX_ATTR_UNLISTED_DENTS on a directory that does cell lookup for
>     non-existent names and mounts them (typically mounted on /afs with -o
>     autocell).  The resulting directories are marked STATX_ATTR_FABRICATED
>     as they do not actually exist in the mounted AFS directory.
> 
> (4) Files, directories and symlinks accessed over AFS are marked
>     STATX_ATTR_REMOTE.
> 
> STATX_ATIME, STATX_CTIME and STATX_BLOCKS are cleared as AFS does not
> support them.

Rather than clearing specific flags, wouldn't it be better to explicitly
set the flags that are actually being returned?  Otherwise, this would
have the problem that Dave pointed out on the 0/4 patch, that there may
be flags still set from userspace that do not mean anything to AFS.

Cheers, Andreas

> 
> Example output:
> 
> 	[root@andromeda ~]# ./samples/statx/test-statx /afs
> 	statx(/afs) = 0
> 	results=7ef
> 	  Size: 2048            Blocks: 0          IO Block: 4096    directory
> 	Device: 00:25           Inode: 1           Links: 2
> 	Access: (0777/drwxrwxrwx)  Uid:     0   Gid:     0
> 	Access: 2006-05-07 00:21:15.000000000+0100
> 	Modify: 2006-05-07 00:21:15.000000000+0100
> 	Change: 2006-05-07 00:21:15.000000000+0100
> 	IO-blocksize: blksize=4096
> 
> Signed-off-by: David Howells <dhowells@redhat.com>
> ---
> 
> fs/afs/inode.c |   21 ++++++++++++++++-----
> 1 file changed, 16 insertions(+), 5 deletions(-)
> 
> diff --git a/fs/afs/inode.c b/fs/afs/inode.c
> index 86cc7264c21c..b08c405a7e1b 100644
> --- a/fs/afs/inode.c
> +++ b/fs/afs/inode.c
> @@ -72,9 +72,9 @@ static int afs_inode_map_status(struct afs_vnode *vnode, struct key *key)
> 	inode->i_uid		= vnode->status.owner;
> 	inode->i_gid		= GLOBAL_ROOT_GID;
> 	inode->i_size		= vnode->status.size;
> -	inode->i_ctime.tv_sec	= vnode->status.mtime_server;
> -	inode->i_ctime.tv_nsec	= 0;
> -	inode->i_atime		= inode->i_mtime = inode->i_ctime;
> +	inode->i_mtime.tv_sec	= vnode->status.mtime_server;
> +	inode->i_mtime.tv_nsec	= 0;
> +	inode->i_atime		= inode->i_ctime = inode->i_mtime;
> 	inode->i_blocks		= 0;
> 	inode->i_generation	= vnode->fid.unique;
> 	inode->i_version	= vnode->status.data_version;
> @@ -375,8 +375,7 @@ int afs_validate(struct afs_vnode *vnode, struct key *key)
> /*
>  * read the attributes of an inode
>  */
> -int afs_getattr(struct vfsmount *mnt, struct dentry *dentry,
> -		      struct kstat *stat)
> +int afs_getattr(struct vfsmount *mnt, struct dentry *dentry, struct kstat *stat)
> {
> 	struct inode *inode;
> 
> @@ -385,6 +384,18 @@ int afs_getattr(struct vfsmount *mnt, struct dentry *dentry,
> 	_enter("{ ino=%lu v=%u }", inode->i_ino, inode->i_generation);
> 
> 	generic_fillattr(inode, stat);
> +
> +	stat->result_mask &= ~(STATX_ATIME | STATX_CTIME | STATX_BLOCKS);
> +	stat->result_mask |= STATX_VERSION;
> +	stat->version = inode->i_version;
> +
> +	if (test_bit(AFS_VNODE_AUTOCELL, &AFS_FS_I(inode)->flags))
> +		stat->attributes |= STATX_ATTR_UNLISTED_DENTS;
> +
> +	if (test_bit(AFS_VNODE_PSEUDODIR, &AFS_FS_I(inode)->flags))
> +		stat->attributes |= STATX_ATTR_FABRICATED;
> +	else
> +		stat->attributes |= STATX_ATTR_REMOTE;
> 	return 0;
> }
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


Cheers, Andreas






[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [RFC][PATCH 0/4] Enhanced file stat system call
  2016-11-18  2:30     ` Andreas Dilger
@ 2016-11-18  4:29       ` NeilBrown
  0 siblings, 0 replies; 52+ messages in thread
From: NeilBrown @ 2016-11-18  4:29 UTC (permalink / raw)
  To: Andreas Dilger, J. Bruce Fields
  Cc: David Howells, One Thousand Gnomes, linux-fsdevel, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 4499 bytes --]

On Fri, Nov 18 2016, Andreas Dilger wrote:

> [ Unknown signature status ]
>
>> On Nov 17, 2016, at 1:00 PM, J. Bruce Fields <bfields@fieldses.org> wrote:
>> 
>> On Thu, Nov 17, 2016 at 04:45:45PM +0000, David Howells wrote:
>>> One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> wrote:
>>> 
>>>>> (2) Lightweight stat (AT_STATX_DONT_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_STATX_FORCE_SYNC): Force a network fs to flush
>>>>>     buffers and go to the server, even if it thinks its cached attributes
>>>>>     are up to date.
>>>> 
>>>> That seems an odd way to do it. Wouldn't it be cleaner and more flexible
>>>> to give a timestamp of the oldest time you consider acceptable (and
>>>> obviously passing 0 indicates whatever you have)
>>> 
>>> Perhaps, though adding 6-argument syscalls is apparently frowned upon.
>>> 
>>>>> 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.
>>>> 
>>>> and dfd + a name gives you fstatat() ?
>>> 
>>> Yes.
>>> 
>>>> The cover note could be clearer on this.
>>> 
>>> Fixed.
>>> 
>>>> Should the fields really be split the way they are for times rather than
>>>> a struct for each one so you can write code generically to handle one of
>>>> those rather than having to have a 4 way switch statement all the time.
>>> 
>>> It depends.  Doing so leaves 16 bytes of hole in the structure.  I could
>>> ameliorate the wastage by using a union to overlay useful fields in the gaps,
>>> but that's pretty icky and might be compiler dependent.
>>> 
>>>> Another attribute that would be nice (but migt need some trivial device
>>>> layer tweaking) would be STATX_ATTR_VOLATILE for filesystems that will
>>>> probably evaporate on a reboot. That's useful information for tools like
>>>> installers and also for sanity checking things like backup paths.
>>> 
>>> There's a FILE_ATTRIBUTE_TEMPORARY that I could map for windows filesystems
>>> that could be used with this.
>>> 
>>>> Remote needs to have clear semantics: is ext4fs over nbd 'remote' for
>>>> example ?
>>> 
>>> Hmmm... Interesting question.  Probably should.  But you could be insane and
>>> RAID an nbd and a local disk.  Further, does NFS over a loopback device to
>>> nfsd on the same machine qualify as root?  What if that's exposing a local fs
>>> on NBD?  Perhaps I should drop 'REMOTE' for now.  It sounds like something
>>> that a GUI filemanager might find interesting, though.
>> 
>> Sorry, I haven't been paying attention, just popping up for this, but:
>> "shared" might be a more useful term than "remote".
>> 
>> A filesystem that may be mounted from more than one system is "shared".
>> Caching performance and semantics of such a filesystem are more
>> complicated since the filesystem may change out from under us.  This is
>> what makes e.g. the lightweight/heavyweight stat difference more
>> interesting in the shared case.
>> 
>> The filesystem should be able to make that shared/unshared distinction
>> without knowledge of the storage it's sitting on top of.
>> 
>> Answering your questions by that criterion:
>> 
>> 	- ext4/nbd: not shared
>> 	- nfs/lo: shared
>> 
>> But, it's fine with me to drop any features for now as long as we can
>> always add them later.
>
> Please, please, please, let's get the syscall and basic functionality
> landed first, and then nit-pick about extensions later.  This has been
> dragging on for _years_ and bike shedded to death.

I very much agree with this, but I think it will require dropping (not
replacing yet) things that do not have a well defined meaning, including

> 	STATX_ATTR_KERNEL_API		File is kernel API (eg: procfs/sysfs)
> 	STATX_ATTR_REMOTE		File is remote and needs network
> 	STATX_ATTR_FABRICATED		File was made up by fs

Without clear guidance on how the filesystem should choose to set these,
and how a program should interpret them, they are worse than noise.
I imagine each could possibly be useful, but without clear unambiguous
documentation, they aren't.
So just remove them for now, and consider adding them once the core
syscall has landed.

NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 800 bytes --]

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [PATCH 4/4] statx: AFS: Return enhanced file attributes
  2016-11-17 13:35 ` [PATCH 4/4] statx: AFS: " David Howells
  2016-11-18  3:34   ` Andreas Dilger
@ 2016-11-18  8:47   ` David Howells
  1 sibling, 0 replies; 52+ messages in thread
From: David Howells @ 2016-11-18  8:47 UTC (permalink / raw)
  To: Andreas Dilger; +Cc: dhowells, linux-fsdevel, linux-kernel

Andreas Dilger <adilger@dilger.ca> wrote:

> > STATX_ATIME, STATX_CTIME and STATX_BLOCKS are cleared as AFS does not
> > support them.
> 
> Rather than clearing specific flags, wouldn't it be better to explicitly
> set the flags that are actually being returned?  Otherwise, this would
> have the problem that Dave pointed out on the 0/4 patch, that there may
> be flags still set from userspace that do not mean anything to AFS.

I'm not sure it make a difference.  generic_fillattr() has to initialise
result_mask to STATX_BASIC_STATS for the support of any unmodified filesystem.
We can then either clear the bits we don't want or just overwrite the mask
entirely with the bits we do want.

Bits in request_mask that are beyond STATX_BASIC_STATS are not automatically
propagated to result_mask.

Possibly vfs_xgetattr_nosec() should preset the result_mask rather than doing
this in generic_fillattr().

David

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available
  2016-11-17 13:35 ` [PATCH 1/4] statx: Add a system call to make enhanced file info available David Howells
  2016-11-17 18:39   ` Jeff Layton
  2016-11-17 23:40   ` Dave Chinner
@ 2016-11-18  8:48   ` David Howells
  2016-11-18 12:01     ` Jeff Layton
  2016-11-18  9:36   ` David Howells
                     ` (2 subsequent siblings)
  5 siblings, 1 reply; 52+ messages in thread
From: David Howells @ 2016-11-18  8:48 UTC (permalink / raw)
  To: Jeff Layton; +Cc: dhowells, linux-fsdevel, linux-kernel

Jeff Layton <jlayton@redhat.com> wrote:

> > If neither AT_STATX_*_SYNC flag is set, the behaviour is the default for
> > stat() on that filesystem.
> > 
> 
> We also need to specify here what happens if both bits are set. Should
> that be -EINVAL?

Makes sense.

This leads to another thought: should fstatat() be allowed to take AT_STATX_*
flags?

David

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available
@ 2016-11-18  8:59       ` David Howells
  0 siblings, 0 replies; 52+ messages in thread
From: David Howells @ 2016-11-18  8:59 UTC (permalink / raw)
  To: Andreas Dilger
  Cc: dhowells, Jeff Layton, linux-fsdevel, linux-kernel, drepper, linux-api

Andreas Dilger <adilger@dilger.ca> wrote:

> >> If neither AT_STATX_*_SYNC flag is set, the behaviour is the default for
> >> stat() on that filesystem.
> > 
> > We also need to specify here what happens if both bits are set. Should
> > that be -EINVAL?
> 
> If that is the case, then it doesn't make sense to have two contradictory
> flags.

Yes it does.  There are actually *three* cases, not two.  Maybe, rather than a
pair of flags, I should stake out a 2-bit field with three possible values.

> Pick a default behaviour (i.e. return what is known on the client),

The default behaviour has to be what stat() does now for any particular
filesystem.  statx() is likely to get used to emulate stat() so that stat()
can be made to return safe timestamps.  If we make it so that statx() cannot
do this, it's very likely that we'll see yet another stat() variant syscall
being added.

> and if this is 100% accurate (e.g. local filesystem or filesystem with
> strong coherency)

In a netfs, it was 100% accurate at the point the server started transmitting
its reply.  This may no longer be true - even with something like AFS that has
change notifications.

> then it can optionally set the SYNC flag in the returned
> flags.

So you suggest putting the SYNC flag(s) in the request mask rather than
sharing the AT_* flag space?

> If the application needs 100% accurate size info, then it can set the SYNC
> flag in the request and the filesystem may need to do extra work to fetch
> accurate data from the server.

Note that one of the things that people asked for was a
DONT_GO_TO_THE_SERVER_AT_ALL flag.  I take it this is your suggested default?

David

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available
@ 2016-11-18  8:59       ` David Howells
  0 siblings, 0 replies; 52+ messages in thread
From: David Howells @ 2016-11-18  8:59 UTC (permalink / raw)
  To: Andreas Dilger
  Cc: dhowells-H+wXaHxf7aLQT0dZR+AlfA, Jeff Layton,
	linux-fsdevel-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	drepper-Re5JQEeQqe8AvxtiuMwx3w, linux-api-u79uwXL29TY76Z2rM5mHXA

Andreas Dilger <adilger-m1MBpc4rdrD3fQ9qLvQP4Q@public.gmane.org> wrote:

> >> If neither AT_STATX_*_SYNC flag is set, the behaviour is the default for
> >> stat() on that filesystem.
> > 
> > We also need to specify here what happens if both bits are set. Should
> > that be -EINVAL?
> 
> If that is the case, then it doesn't make sense to have two contradictory
> flags.

Yes it does.  There are actually *three* cases, not two.  Maybe, rather than a
pair of flags, I should stake out a 2-bit field with three possible values.

> Pick a default behaviour (i.e. return what is known on the client),

The default behaviour has to be what stat() does now for any particular
filesystem.  statx() is likely to get used to emulate stat() so that stat()
can be made to return safe timestamps.  If we make it so that statx() cannot
do this, it's very likely that we'll see yet another stat() variant syscall
being added.

> and if this is 100% accurate (e.g. local filesystem or filesystem with
> strong coherency)

In a netfs, it was 100% accurate at the point the server started transmitting
its reply.  This may no longer be true - even with something like AFS that has
change notifications.

> then it can optionally set the SYNC flag in the returned
> flags.

So you suggest putting the SYNC flag(s) in the request mask rather than
sharing the AT_* flag space?

> If the application needs 100% accurate size info, then it can set the SYNC
> flag in the request and the filesystem may need to do extra work to fetch
> accurate data from the server.

Note that one of the things that people asked for was a
DONT_GO_TO_THE_SERVER_AT_ALL flag.  I take it this is your suggested default?

David

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available
@ 2016-11-18  9:25         ` Andreas Dilger
  0 siblings, 0 replies; 52+ messages in thread
From: Andreas Dilger @ 2016-11-18  9:25 UTC (permalink / raw)
  To: David Howells
  Cc: Jeff Layton, linux-fsdevel, linux-kernel, drepper, linux-api

[-- Attachment #1: Type: text/plain, Size: 2529 bytes --]

On Nov 18, 2016, at 1:59 AM, David Howells <dhowells@redhat.com> wrote:
> 
> Andreas Dilger <adilger@dilger.ca> wrote:
> 
>>>> If neither AT_STATX_*_SYNC flag is set, the behaviour is the default for
>>>> stat() on that filesystem.
>>> 
>>> We also need to specify here what happens if both bits are set. Should
>>> that be -EINVAL?
>> 
>> If that is the case, then it doesn't make sense to have two contradictory
>> flags.
> 
> Yes it does.  There are actually *three* cases, not two.  Maybe, rather
> than a pair of flags, I should stake out a 2-bit field with three possible
> values.

That would probably be better in this case.

>> Pick a default behaviour (i.e. return what is known on the client),
> 
> The default behaviour has to be what stat() does now for any particular
> filesystem.  statx() is likely to get used to emulate stat() so that stat()
> can be made to return safe timestamps.  If we make it so that statx() cannot
> do this, it's very likely that we'll see yet another stat() variant syscall
> being added.
> 
>> and if this is 100% accurate (e.g. local filesystem or filesystem with
>> strong coherency)
> 
> In a netfs, it was 100% accurate at the point the server started
> transmitting its reply.  This may no longer be true - even with something
> like AFS that has change notifications.

Sure, that is always true, even when running with a local filesystem.
My distinction here is "whether the client currently has a lock that
ensures its copy of the size is correct" vs. "the client has some size
that was correct at one point but may be totally incorrect now".

>> then it can optionally set the SYNC flag in the returned
>> flags.
> 
> So you suggest putting the SYNC flag(s) in the request mask rather than
> sharing the AT_* flag space?

Sorry, I was conflating flags.

>> If the application needs 100% accurate size info, then it can set the SYNC
>> flag in the request and the filesystem may need to do extra work to fetch
>> accurate data from the server.
> 
> Note that one of the things that people asked for was a
> DONT_GO_TO_THE_SERVER_AT_ALL flag.  I take it this is your suggested default?

Isn't that what NFS does today?

In any case, I'm not trying to rewrite NFS semantics here.  The main fix
would be to have the three-valued two-bit flag so that there aren't two
flags that mean opposite things.  That would also allow expansion to have
a fourth state in the future, if there was a need.

Cheers, Andreas






[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available
@ 2016-11-18  9:25         ` Andreas Dilger
  0 siblings, 0 replies; 52+ messages in thread
From: Andreas Dilger @ 2016-11-18  9:25 UTC (permalink / raw)
  To: David Howells
  Cc: Jeff Layton, linux-fsdevel-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	drepper-Re5JQEeQqe8AvxtiuMwx3w, linux-api-u79uwXL29TY76Z2rM5mHXA

[-- Attachment #1: Type: text/plain, Size: 2588 bytes --]

On Nov 18, 2016, at 1:59 AM, David Howells <dhowells-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> 
> Andreas Dilger <adilger-m1MBpc4rdrD3fQ9qLvQP4Q@public.gmane.org> wrote:
> 
>>>> If neither AT_STATX_*_SYNC flag is set, the behaviour is the default for
>>>> stat() on that filesystem.
>>> 
>>> We also need to specify here what happens if both bits are set. Should
>>> that be -EINVAL?
>> 
>> If that is the case, then it doesn't make sense to have two contradictory
>> flags.
> 
> Yes it does.  There are actually *three* cases, not two.  Maybe, rather
> than a pair of flags, I should stake out a 2-bit field with three possible
> values.

That would probably be better in this case.

>> Pick a default behaviour (i.e. return what is known on the client),
> 
> The default behaviour has to be what stat() does now for any particular
> filesystem.  statx() is likely to get used to emulate stat() so that stat()
> can be made to return safe timestamps.  If we make it so that statx() cannot
> do this, it's very likely that we'll see yet another stat() variant syscall
> being added.
> 
>> and if this is 100% accurate (e.g. local filesystem or filesystem with
>> strong coherency)
> 
> In a netfs, it was 100% accurate at the point the server started
> transmitting its reply.  This may no longer be true - even with something
> like AFS that has change notifications.

Sure, that is always true, even when running with a local filesystem.
My distinction here is "whether the client currently has a lock that
ensures its copy of the size is correct" vs. "the client has some size
that was correct at one point but may be totally incorrect now".

>> then it can optionally set the SYNC flag in the returned
>> flags.
> 
> So you suggest putting the SYNC flag(s) in the request mask rather than
> sharing the AT_* flag space?

Sorry, I was conflating flags.

>> If the application needs 100% accurate size info, then it can set the SYNC
>> flag in the request and the filesystem may need to do extra work to fetch
>> accurate data from the server.
> 
> Note that one of the things that people asked for was a
> DONT_GO_TO_THE_SERVER_AT_ALL flag.  I take it this is your suggested default?

Isn't that what NFS does today?

In any case, I'm not trying to rewrite NFS semantics here.  The main fix
would be to have the three-valued two-bit flag so that there aren't two
flags that mean opposite things.  That would also allow expansion to have
a fourth state in the future, if there was a need.

Cheers, Andreas






[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available
  2016-11-17 13:35 ` [PATCH 1/4] statx: Add a system call to make enhanced file info available David Howells
                     ` (2 preceding siblings ...)
  2016-11-18  8:48   ` David Howells
@ 2016-11-18  9:36   ` David Howells
  2016-11-18 17:17     ` Jeff Layton
  2016-11-18 18:04     ` David Howells
  2016-11-18  9:43   ` David Howells
  2016-11-18 10:29     ` David Howells
  5 siblings, 2 replies; 52+ messages in thread
From: David Howells @ 2016-11-18  9:36 UTC (permalink / raw)
  To: Dave Chinner; +Cc: dhowells, linux-fsdevel, linux-kernel

Dave Chinner <david@fromorbit.com> wrote:

> >  (5) Data version number: Could be used by userspace NFS servers [Aneesh
> >      Kumar].
> > 
> >      Can also be used to modify fill_post_wcc() in NFSD which retrieves
> >      i_version directly, but has just called vfs_getattr().  It could get
> >      it from the kstat struct if it used vfs_xgetattr() instead.
> 
> This needs a much clearer name that stx_version as "version" is
> entirely ambiguous. e.g. Inodes have internal version numbers to
> disambiguate life cycles. and there are versioning filesystems
> which have multiple versions of the same file. 

We've already been through that.  I wanted to call it stx_data_version but
that got argued down to stx_version.  The problem is that what the version
number means is entirely filesystem dependent, and it might not just reflect
changes in the data.

> So if stx_version this is intended to export the internal filesystem
> inode change counter (i.e. inode->i_version) then lets call it that:
> stx_modification_count. It's clear and unambiguous as to what it
> represents, especially as this counter is more than just a "data
> modification" counter - inode metadata modifications will also
> cause it to change....

I disagree that it's unambiguous.  It works like mtime, right?

Which wouldn't be of use for certain filesystems.  An example of this would be
AFS, where it's incremented by 1 each time a write is committed, but is not
updated for metadata changes.  This is what matters for data caching.

> > (13) FS_IOC_GETFLAGS value.  These could be translated to BSD's st_flags.
> >      Note that the Linux IOC flags are a mess and filesystems such as Ext4
> >      define flags that aren't in linux/fs.h, so translation in the kernel
> >      may be a necessity (or, possibly, we provide the filesystem type too).
> 
> And we now also have FS_IOC_FSGETXATTR that extends the flags
> and information userspace can get from filesystems. It makes little
> sense to now add xstat() and not add everything this interface
> also exports...

I'm not sure I agree.  Stuff like extent sizes and extent hint flags seem like
very specialised things that don't belong in the stat interface.  The project
ID, on the other hand is arguably a good thing to include.  But we can always
add this later.

Note that are also two variants of the fsxattr struct defined in the kernel -
though one is a superset of the other.

> > Time fields are split into separate seconds and nanoseconds fields to make
> > packing easier and the granularities can be queried with the filesystem
> > info system call.  Note that times will be negative if before 1970; in such
> > a case, the nanosecond fields will also be negative if not zero.
> 
> So what happens in ten years time when we want to support
> femptosecond resolution in the timestamp interface? We've got to
> change everything to 64 bit? Shouldn't we just make everything
> timestamp related 64 bit?

You really think we're going to have accurate timestamps with a resolution of
a millionth of a nanosecond?  This means you're going to be doing a 64-bit
division every time you want a nanosecond timestamp.

Also, violet light has a period of ~1.2fs so your 1fs oscillator might emit UV
radiation.

> > The bits defined in the stx_attributes field convey information about a
> > file, how it is accessed, where it is and what it does.  The following
> > attributes map to FS_*_FL flags and are the same numerical value:
> 
> Please isolate the new interface flags completely from the FS_*_FL
> values. We should not repeat the mistake of tying values derived
> from filesystem specific on-disk values to a user interface. 

Why shouldn't I make a numerical correspondance with at least one set of such
flags?  I get to define a whole new numberspace and can pick the values I
want.  I see no particular reason to pick explicitly non-corresponding values
where possible.

Now, I can agree that the code should say, for example:

	if (ext4->flag & FS_COMPRESSED_FL)
		statx.attr |= STATX_ATTR_COMPRESSED;
	if (ext4->flag & FS_ENCRYPTED_FL)
		statx.attr |= STATX_ATTR_ENCRYPTED;
	if (ext4->flag & FS_IMMUTABLE_FL)
		statx.attr |= STATX_ATTR_IMMUTABLE;
	...

and that the *compiler* should collapse this to:

	statx.attr |= ext4->flag & mask;

but see:

	https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78317

David

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available
  2016-11-17 13:35 ` [PATCH 1/4] statx: Add a system call to make enhanced file info available David Howells
                     ` (3 preceding siblings ...)
  2016-11-18  9:36   ` David Howells
@ 2016-11-18  9:43   ` David Howells
  2016-11-18 21:41     ` Dave Chinner
  2016-11-18 22:24     ` David Howells
  2016-11-18 10:29     ` David Howells
  5 siblings, 2 replies; 52+ messages in thread
From: David Howells @ 2016-11-18  9:43 UTC (permalink / raw)
  To: Dave Chinner; +Cc: dhowells, linux-fsdevel, linux-kernel

Dave Chinner <david@fromorbit.com> wrote:

> > 	STATX_ATTR_KERNEL_API		File is kernel API (eg: procfs/sysfs)
> > 	STATX_ATTR_REMOTE		File is remote and needs network
> > 	STATX_ATTR_FABRICATED		File was made up by fs
> 
> Every file is fabricated by a filesystem :P
> 
> Perhaps you're wanting "virtual file" because it is has no physical
> presence?

Yeah - that might be a better name.  The idea of FABRICATED is to note objects
that have no actual existence in the backing store.  Directories that had to
be invented to act as mountpoints would be a good example of this.

> > Fields in struct statx come in a number of classes:
> > 
> >  (0) stx_dev_*, stx_blksize.
> > 
> >      These are local system information and are always available.
> 
> What does stx_blksize actually mean? It's completely ambiguous in
> stat() because we don't actually report the physical block size
> here - we report the "minimum unit of efficient IO" that we expect
> applications to use. Please define :P

Definition: "Same as struct stat::st_blksize".

> > The following test program can be used to test the statx system call:
> > 
> > 	samples/statx/test-statx.c
> > 
> > Just compile and run, passing it paths to the files you want to examine.
> > The file is built automatically if CONFIG_SAMPLES is enabled.
> 
> Can we get xfstests written to exercise and validate all this
> functionality, please? I'd suggest that adding xfs_io support for
> the statx syscall would be far more useful for xfstests than a
> standalone  test program, too. We already have equivalent stat()
> functionality in xfs_io and that's used quite a bit in xfstests....

Feel free to write some! ;-)

But I need a simple standalone test program to be able to test what I write,
and I've no inclination to wheel out huge testsuites for an interface that
people are still arguing about and wanting changed.

David

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available
  2016-11-17 23:40   ` Dave Chinner
  2016-11-18  3:28     ` Andreas Dilger
@ 2016-11-18  9:53     ` David Howells
  1 sibling, 0 replies; 52+ messages in thread
From: David Howells @ 2016-11-18  9:53 UTC (permalink / raw)
  To: Andreas Dilger; +Cc: dhowells, Dave Chinner, linux-fsdevel, linux-kernel

Andreas Dilger <adilger@dilger.ca> wrote:

> > What happens when an application uses STATX_ALL from a future kernel
> > that defines more flags than are initially supported, and that
> > application then is run on a kernel that onyl supports the initial
> > fields?
> 
> Fields that are unknown by the current kernel/filesystem will not be set,
> and this is reflected in the flags that are returned to userspace.

Yep.

A userspace program can stick 0xffffffff in there if it wants.  No error will
be incurred.  It just won't necessarily get anything back for each of those
bits.  That said, if we, say, want to reserve bit 31 as a struct extension
bit, sticking in 0xffffffff without knowing what this is going to do to you on
a kernel that supports a longer struct might give you a problem.

But, basically, STATX_ALL indicates what flags have fields in the copy of the
struct you got from the header file.

There's an extra scenario: you could compile your userspace program against
the headers for a particular kernel and then run against a later kernel.  In
such a case, you may find bits set that are outside STATX_ALL in stx_mask.
However, you don't have definitions for those bits and can only ignore them.

> > Again, we have many more common and extended flags than this.
> > NOATIME and SYNC are two that immediately come to mind as generic
> > flags that should be in this...
> 
> Sure, and they can be added incrementally in a later patch.  I'm not
> sure why NOATIME and SYNC are missing, and I'm not against adding them,
> but it is equally likely that they were removed in a previous round of
> bikeshedding to avoid some real or perceived issue, so that this patch
> can finally land rather than being in limbo for another 5 years.

Does it make sense to return them through statx?  Note that NOATIME might be
considered superfluous given that STATX_ATIME is cleared in such a case.

> >> New flags include:
> >> 
> >> 	STATX_ATTR_NONUNIX_OWNERSHIP	File doesn't have Unixy ownership
> >> 	STATX_ATTR_HAS_ACL		File has an ACL
> > 
> > So statx will require us to do ACL lookups? i.e. instead of just
> > reading the inode to get the information, we'll also have to do
> > extended attribute lookups? That's potentially very expensive if
> > the extended attribute is not stored in the inode....
> 
> No, there is no requirement to return anything that the caller didn't
> ask for.  Only fields that are explicitly requested need to be returned,
> and others can optionally be returned if it is easy for the filesystem
> to do so.

Actually, Dave might have a point.  We don't necessarily know that the file
has an ACL without doing a getxattr() to probe for it - on the other hand, I
would expect the permissions check to have done precisely that.

David

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available
  2016-11-17 13:35 ` [PATCH 1/4] statx: Add a system call to make enhanced file info available David Howells
@ 2016-11-18 10:29     ` David Howells
  2016-11-17 23:40   ` Dave Chinner
                       ` (4 subsequent siblings)
  5 siblings, 0 replies; 52+ messages in thread
From: David Howells @ 2016-11-18 10:29 UTC (permalink / raw)
  To: Dave Chinner; +Cc: dhowells, linux-fsdevel, linux-kernel, linux-api

Dave Chinner <david@fromorbit.com> wrote:

> > (13) FS_IOC_GETFLAGS value.  These could be translated to BSD's st_flags.
> >      Note that the Linux IOC flags are a mess and filesystems such as Ext4
> >      define flags that aren't in linux/fs.h, so translation in the kernel
> >      may be a necessity (or, possibly, we provide the filesystem type too).
> 
> And we now also have FS_IOC_FSGETXATTR that extends the flags
> and information userspace can get from filesystems.

Btw, can you point me at the manpage that defines the fsxattr struct and its
flags?

Also, ioctl_list(2) should probably include FS_IOC_FS[GS]ETXATTR.

David

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available
@ 2016-11-18 10:29     ` David Howells
  0 siblings, 0 replies; 52+ messages in thread
From: David Howells @ 2016-11-18 10:29 UTC (permalink / raw)
  To: Dave Chinner
  Cc: dhowells-H+wXaHxf7aLQT0dZR+AlfA,
	linux-fsdevel-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	linux-api-u79uwXL29TY76Z2rM5mHXA

Dave Chinner <david-FqsqvQoI3Ljby3iVrkZq2A@public.gmane.org> wrote:

> > (13) FS_IOC_GETFLAGS value.  These could be translated to BSD's st_flags.
> >      Note that the Linux IOC flags are a mess and filesystems such as Ext4
> >      define flags that aren't in linux/fs.h, so translation in the kernel
> >      may be a necessity (or, possibly, we provide the filesystem type too).
> 
> And we now also have FS_IOC_FSGETXATTR that extends the flags
> and information userspace can get from filesystems.

Btw, can you point me at the manpage that defines the fsxattr struct and its
flags?

Also, ioctl_list(2) should probably include FS_IOC_FS[GS]ETXATTR.

David

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available
  2016-11-18  8:48   ` David Howells
@ 2016-11-18 12:01     ` Jeff Layton
  0 siblings, 0 replies; 52+ messages in thread
From: Jeff Layton @ 2016-11-18 12:01 UTC (permalink / raw)
  To: David Howells; +Cc: linux-fsdevel, linux-kernel

On Fri, 2016-11-18 at 08:48 +0000, David Howells wrote:
> Jeff Layton <jlayton@redhat.com> wrote:
> 
> > 
> > > 
> > > If neither AT_STATX_*_SYNC flag is set, the behaviour is the default for
> > > stat() on that filesystem.
> > > 
> > 
> > We also need to specify here what happens if both bits are set. Should
> > that be -EINVAL?
> 
> Makes sense.
> 
> This leads to another thought: should fstatat() be allowed to take AT_STATX_*
> flags?
> 
> David

In principle, we could. fstatat currently rejects flags that it doesn't
understand with -EINVAL.

That said, I'd vote no -- if you wanted to change an application to
start setting these flags in fstatat calls, then it's just as simple to
convert it over to use statx. I don't see a lot of benefit in adding
that to a legacy syscall.

-- 
Jeff Layton <jlayton@redhat.com>

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [RFC][PATCH 0/4] Enhanced file stat system call
  2016-11-17 16:45 ` David Howells
  2016-11-17 20:00   ` J. Bruce Fields
@ 2016-11-18 13:41   ` One Thousand Gnomes
  2016-11-18 13:49   ` David Howells
  2 siblings, 0 replies; 52+ messages in thread
From: One Thousand Gnomes @ 2016-11-18 13:41 UTC (permalink / raw)
  To: David Howells; +Cc: linux-fsdevel, linux-kernel

> Hmmm... Interesting question.  Probably should.  But you could be insane and
> RAID an nbd and a local disk.  Further, does NFS over a loopback device to
> nfsd on the same machine qualify as root?  What if that's exposing a local fs
> on NBD?  Perhaps I should drop 'REMOTE' for now.  It sounds like something
> that a GUI filemanager might find interesting, though.

GUI file managers already try and guess some of this in order to decide
whether to display icons off remote file systems.

You could be insane but it's always going to be a hint and nothing more
and if it can't be perfect then that just goes in the notes in the manual
page.

Alan

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [RFC][PATCH 0/4] Enhanced file stat system call
  2016-11-17 16:45 ` David Howells
  2016-11-17 20:00   ` J. Bruce Fields
  2016-11-18 13:41   ` One Thousand Gnomes
@ 2016-11-18 13:49   ` David Howells
  2 siblings, 0 replies; 52+ messages in thread
From: David Howells @ 2016-11-18 13:49 UTC (permalink / raw)
  To: One Thousand Gnomes; +Cc: dhowells, linux-fsdevel, linux-kernel

One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> wrote:

> > Hmmm... Interesting question.  Probably should.  But you could be insane and
> > RAID an nbd and a local disk.  Further, does NFS over a loopback device to
> > nfsd on the same machine qualify as root?  What if that's exposing a local fs
> > on NBD?  Perhaps I should drop 'REMOTE' for now.  It sounds like something
> > that a GUI filemanager might find interesting, though.
> 
> GUI file managers already try and guess some of this in order to decide
> whether to display icons off remote file systems.
> 
> You could be insane but it's always going to be a hint and nothing more
> and if it can't be perfect then that just goes in the notes in the manual
> page.

I've dropped REMOTE, FABRICATED, KERNEL_API, NONUNIX_OWNERSHIP, HAS_ACL and
UNLISTED_DENTS for now.  I'm keeping AUTOMOUNT as that seems fairly
straightforward - though I'm sure we can find someone to disagree! ;-)

David

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available
  2016-11-18  9:36   ` David Howells
@ 2016-11-18 17:17     ` Jeff Layton
  2016-11-18 18:04     ` David Howells
  1 sibling, 0 replies; 52+ messages in thread
From: Jeff Layton @ 2016-11-18 17:17 UTC (permalink / raw)
  To: David Howells, Dave Chinner; +Cc: linux-fsdevel, linux-kernel

On Fri, 2016-11-18 at 09:36 +0000, David Howells wrote:
> Dave Chinner <david@fromorbit.com> wrote:
> 
> > >  (5) Data version number: Could be used by userspace NFS servers [Aneesh
> > >      Kumar].
> > > 
> > >      Can also be used to modify fill_post_wcc() in NFSD which retrieves
> > >      i_version directly, but has just called vfs_getattr().  It could get
> > >      it from the kstat struct if it used vfs_xgetattr() instead.
> > 
> > This needs a much clearer name that stx_version as "version" is
> > entirely ambiguous. e.g. Inodes have internal version numbers to
> > disambiguate life cycles. and there are versioning filesystems
> > which have multiple versions of the same file. 
> 
> We've already been through that.  I wanted to call it stx_data_version but
> that got argued down to stx_version.  The problem is that what the version
> number means is entirely filesystem dependent, and it might not just reflect
> changes in the data.
> 

It had better not just reflect data changes.

knfsd populates the NFSv4 change attribute from inode->i_version. It
_must_ have changed between subsequent queries if either the data or
metadata has changed (basically whenever you would update either the
ctime or the mtime).


> > So if stx_version this is intended to export the internal filesystem
> > inode change counter (i.e. inode->i_version) then lets call it that:
> > stx_modification_count. It's clear and unambiguous as to what it
> > represents, especially as this counter is more than just a "data
> > modification" counter - inode metadata modifications will also
> > cause it to change....
> 
> I disagree that it's unambiguous.  It works like mtime, right?
> 

More like ctime + mtime mashed together.

> Which wouldn't be of use for certain filesystems.  An example of this would be
> AFS, where it's incremented by 1 each time a write is committed, but is not
> updated for metadata changes.  This is what matters for data caching.
> 

No. Basically the rules are that if something in the inode data or
metadata changed, then it must be a "larger" value (also accounting for
wraparound). So you also need to change it (usually by incrementing it)
when doing namespace changes that involve it (renames, unlinks, etc.).

> > > (13) FS_IOC_GETFLAGS value.  These could be translated to BSD's st_flags.
> > >      Note that the Linux IOC flags are a mess and filesystems such as Ext4
> > >      define flags that aren't in linux/fs.h, so translation in the kernel
> > >      may be a necessity (or, possibly, we provide the filesystem type too).
> > 
> > And we now also have FS_IOC_FSGETXATTR that extends the flags
> > and information userspace can get from filesystems. It makes little
> > sense to now add xstat() and not add everything this interface
> > also exports...
> 
> I'm not sure I agree.  Stuff like extent sizes and extent hint flags seem like
> very specialised things that don't belong in the stat interface.  The project
> ID, on the other hand is arguably a good thing to include.  But we can always
> add this later.
> 

Yes. The entire point of this interface is that it is extendable.

I'm all for simplicity here and just adding the bare minimum of fields
to get the new interface in. The main thing we must do here though is
to ID anything that would hobble us from being able to add new
attributes later.

Adding new fields in later piecemeal patches allows us to demonstrate
that that concept actually works.

> Note that are also two variants of the fsxattr struct defined in the kernel -
> though one is a superset of the other.
> 
> > > Time fields are split into separate seconds and nanoseconds fields to make
> > > packing easier and the granularities can be queried with the filesystem
> > > info system call.  Note that times will be negative if before 1970; in such
> > > a case, the nanosecond fields will also be negative if not zero.
> > 
> > So what happens in ten years time when we want to support
> > femptosecond resolution in the timestamp interface? We've got to
> > change everything to 64 bit? Shouldn't we just make everything
> > timestamp related 64 bit?
> 
> You really think we're going to have accurate timestamps with a resolution of
> a millionth of a nanosecond?  This means you're going to be doing a 64-bit
> division every time you want a nanosecond timestamp.
> 
> Also, violet light has a period of ~1.2fs so your 1fs oscillator might emit UV
> radiation.
> 

Could contemporary machines get away with just shifting down by 32
bits?

> > > The bits defined in the stx_attributes field convey information about a
> > > file, how it is accessed, where it is and what it does.  The following
> > > attributes map to FS_*_FL flags and are the same numerical value:
> > 
> > Please isolate the new interface flags completely from the FS_*_FL
> > values. We should not repeat the mistake of tying values derived
> > from filesystem specific on-disk values to a user interface. 
> 
> Why shouldn't I make a numerical correspondance with at least one set of such
> flags?  I get to define a whole new numberspace and can pick the values I
> want.  I see no particular reason to pick explicitly non-corresponding values
> where possible.
> 
> Now, I can agree that the code should say, for example:
> 
> 	if (ext4->flag & FS_COMPRESSED_FL)
> 		statx.attr |= STATX_ATTR_COMPRESSED;
> 	if (ext4->flag & FS_ENCRYPTED_FL)
> 		statx.attr |= STATX_ATTR_ENCRYPTED;
> 	if (ext4->flag & FS_IMMUTABLE_FL)
> 		statx.attr |= STATX_ATTR_IMMUTABLE;
> 	...
> 
> and that the *compiler* should collapse this to:
> 
> 	statx.attr |= ext4->flag & mask;
> 
> but see:
> 
> 	https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78317
> 
> David
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available
  2016-11-18  9:36   ` David Howells
  2016-11-18 17:17     ` Jeff Layton
@ 2016-11-18 18:04     ` David Howells
  2016-11-18 18:54       ` Jeff Layton
  2016-11-18 19:08       ` David Howells
  1 sibling, 2 replies; 52+ messages in thread
From: David Howells @ 2016-11-18 18:04 UTC (permalink / raw)
  To: Jeff Layton; +Cc: dhowells, Dave Chinner, linux-fsdevel, linux-kernel

Jeff Layton <jlayton@poochiereds.net> wrote:

> > We've already been through that.  I wanted to call it stx_data_version but
> > that got argued down to stx_version.  The problem is that what the version
> > number means is entirely filesystem dependent, and it might not just reflect
> > changes in the data.
> > 
> 
> It had better not just reflect data changes.
> 
> knfsd populates the NFSv4 change attribute from inode->i_version. It
> _must_ have changed between subsequent queries if either the data or
> metadata has changed (basically whenever you would update either the
> ctime or the mtime).

No, I think it *should* just reflect the data changes - otherwise you have
have to burn your cached data unnecessarily.

> > > So if stx_version this is intended to export the internal filesystem
> > > inode change counter (i.e. inode->i_version) then lets call it that:
> > > stx_modification_count. It's clear and unambiguous as to what it
> > > represents, especially as this counter is more than just a "data
> > > modification" counter - inode metadata modifications will also
> > > cause it to change....
> > 
> > I disagree that it's unambiguous.  It works like mtime, right?
> 
> More like ctime + mtime mashed together.

Isn't ctime updated every time mtime is?  In which case stx_change_count would
be a better name.

> > Which wouldn't be of use for certain filesystems.  An example of this
> > would be AFS, where it's incremented by 1 each time a write is committed,
> > but is not updated for metadata changes.  This is what matters for data
> > caching.
> > 
> 
> No. Basically the rules are that if something in the inode data or
> metadata changed, then it must be a "larger" value (also accounting for
> wraparound). So you also need to change it (usually by incrementing it)
> when doing namespace changes that involve it (renames, unlinks, etc.).

That's entirely filesystem dependent.

A better rule is that if you do a write and then compare the data version you
got back to the version you had before; if it's increased by exactly one,
there were no other writes between your last retrieval of the attributes and
your write that just got committed.  Admittedly, this assumes that the server
serialises writes to a particular file.

If the value just increases, you don't know that didn't happen by this
mechanism, so the version is of limited value.

> Adding new fields in later piecemeal patches allows us to demonstrate
> that that concept actually works.

You're probably right, but the downside is that we really need some way to
find out what's supported.  On the other hand, we probably need that anyway,
hence my suggestion of an fsinfo() syscall also.

> > You really think we're going to have accurate timestamps with a resolution
> > of a millionth of a nanosecond?  This means you're going to be doing a
> > 64-bit division every time you want a nanosecond timestamp.
> ...
> 
> Could contemporary machines get away with just shifting down by 32
> bits?

A better way would probably be to have:

	struct timestamp {
		__u64 seconds;
		__u32 nanoseconds;
		__u32 femtoseconds;
	};

where you effectively add all the fields together with appropriate
multipliers.

But I still wonder if we really are going to move to femtosecond timestamps,
given that that's going to involve clock frequencies well in excess of 1 THz
to be useful.  Even attoseconds is probably unnecessary, given that clock
frequencies don't seem to be moving much beyond a few GHz, though it's
reasonable that we could have a timestamp counter that has an attosecond
period - it's just that the processing time to deal with it seems likely to
render it unnecessary.

David

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available
  2016-11-18 18:04     ` David Howells
@ 2016-11-18 18:54       ` Jeff Layton
  2016-11-18 19:08       ` David Howells
  1 sibling, 0 replies; 52+ messages in thread
From: Jeff Layton @ 2016-11-18 18:54 UTC (permalink / raw)
  To: David Howells; +Cc: Dave Chinner, linux-fsdevel, linux-kernel

On Fri, 2016-11-18 at 18:04 +0000, David Howells wrote:
> Jeff Layton <jlayton@poochiereds.net> wrote:
> 
> > > We've already been through that.  I wanted to call it stx_data_version but
> > > that got argued down to stx_version.  The problem is that what the version
> > > number means is entirely filesystem dependent, and it might not just reflect
> > > changes in the data.
> > > 
> > 
> > It had better not just reflect data changes.
> > 
> > knfsd populates the NFSv4 change attribute from inode->i_version. It
> > _must_ have changed between subsequent queries if either the data or
> > metadata has changed (basically whenever you would update either the
> > ctime or the mtime).
> 
> No, I think it *should* just reflect the data changes - otherwise you have
> have to burn your cached data unnecessarily.
> 
> > > > So if stx_version this is intended to export the internal filesystem
> > > > inode change counter (i.e. inode->i_version) then lets call it that:
> > > > stx_modification_count. It's clear and unambiguous as to what it
> > > > represents, especially as this counter is more than just a "data
> > > > modification" counter - inode metadata modifications will also
> > > > cause it to change....
> > > 
> > > I disagree that it's unambiguous.  It works like mtime, right?
> > 
> > More like ctime + mtime mashed together.
> 
> Isn't ctime updated every time mtime is?  In which case stx_change_count would
> be a better name.
> 
> > > Which wouldn't be of use for certain filesystems.  An example of this
> > > would be AFS, where it's incremented by 1 each time a write is committed,
> > > but is not updated for metadata changes.  This is what matters for data
> > > caching.
> > > 
> > 
> > No. Basically the rules are that if something in the inode data or
> > metadata changed, then it must be a "larger" value (also accounting for
> > wraparound). So you also need to change it (usually by incrementing it)
> > when doing namespace changes that involve it (renames, unlinks, etc.).
> 
> That's entirely filesystem dependent.
> 

My mistake. I had thought that i_version was only used for NFSv4, and a
few internal callers (particularly, some readdir implementations). I
didn't realize that AFS also uses it.

> A better rule is that if you do a write and then compare the data version you
> got back to the version you had before; if it's increased by exactly one,
> there were no other writes between your last retrieval of the attributes and
> your write that just got committed.  Admittedly, this assumes that the server
> serialises writes to a particular file.
> 
> If the value just increases, you don't know that didn't happen by this
> mechanism, so the version is of limited value.
> 

For the case of NFSv4, you can't infer that anyway. The protocol pretty
much states that the client has to treat this value as semi-opaque. It
can't infer anything other than "something has changed" (though it can
look to see if a change attribute is "old" and discard it).

Does AFS allow you to infer something from the actual value?

Now that I realize that AFS has very different semantics, we might want
to step back for a bit on presenting i_version to userspace. I think we
need to come to some agreement on what i_version should actually mean
before we expose it to userland to use.

Maybe we should consider separate stx_change_attr and
stx_data_change_attr fields in here?

> > Adding new fields in later piecemeal patches allows us to demonstrate
> > that that concept actually works.
> 
> You're probably right, but the downside is that we really need some way to
> find out what's supported.  On the other hand, we probably need that anyway,
> hence my suggestion of an fsinfo() syscall also.
> 

Yeah, I think we will need an fsinfo call of some sort eventually.

Alternately, we could just add the fields of interest to statx so that
the callers can just query for it with the other fields (e.g.
STATX_TS_GRANULARITY). Just document those attributes as being per-
mount or whatever.

> > > You really think we're going to have accurate timestamps with a resolution
> > > of a millionth of a nanosecond?  This means you're going to be doing a
> > > 64-bit division every time you want a nanosecond timestamp.
> > 
> > ...
> > 
> > Could contemporary machines get away with just shifting down by 32
> > bits?
> 
> A better way would probably be to have:
> 
> 	struct timestamp {
> 		__u64 seconds;
> 		__u32 nanoseconds;
> 		__u32 femtoseconds;
> 	};
> 
> where you effectively add all the fields together with appropriate
> multipliers.
> 

Harder for those femtosecond scale machines to deal with, but maybe
you're right.

If the plan is to do that then we can just punt that out until that
need arises, and add stx_?time_fsec fields at that point. The ugliness
would all be hidden behind the glibc wrapper anyway (in principle).

> But I still wonder if we really are going to move to femtosecond timestamps,
> given that that's going to involve clock frequencies well in excess of 1 THz
> to be useful.  Even attoseconds is probably unnecessary, given that clock
> frequencies don't seem to be moving much beyond a few GHz, though it's
> reasonable that we could have a timestamp counter that has an attosecond
> period - it's just that the processing time to deal with it seems likely to
> render it unnecessary.
> 
> David

True, and we have to figure here that these are _file_ times, so you'd
have to have file updates happening on sub-nanosecond timescales for
this to make sense as well.

I don't think we really need to add this now, especially if we can add
the extra fields if/when the need ever arises.

-- 
Jeff Layton <jlayton@redhat.com>

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available
  2016-11-18 18:04     ` David Howells
  2016-11-18 18:54       ` Jeff Layton
@ 2016-11-18 19:08       ` David Howells
  1 sibling, 0 replies; 52+ messages in thread
From: David Howells @ 2016-11-18 19:08 UTC (permalink / raw)
  To: Jeff Layton; +Cc: dhowells, Dave Chinner, linux-fsdevel, linux-kernel

Jeff Layton <jlayton@redhat.com> wrote:

> Does AFS allow you to infer something from the actual value?

Yes.  Given:

 (1) Each write on a file is atomic with respect to all other writes to that
     same file.

 (2) The data version is incremented by exactly one for each write committed,
     and that value is returned in the reply to the write RPC call.

If you think you have a file with version 99, you do a call and get back
version 100, you *know* that there was no conflicting write before your write.

If the version came back as 101, however, you *know* that there was a write
you didn't know about.  Therefore, you have to flush your cache.

David

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available
  2016-11-18 10:29     ` David Howells
  (?)
@ 2016-11-18 21:27     ` Dave Chinner
  -1 siblings, 0 replies; 52+ messages in thread
From: Dave Chinner @ 2016-11-18 21:27 UTC (permalink / raw)
  To: David Howells; +Cc: linux-fsdevel, linux-kernel, linux-api

On Fri, Nov 18, 2016 at 10:29:04AM +0000, David Howells wrote:
> Dave Chinner <david@fromorbit.com> wrote:
> 
> > > (13) FS_IOC_GETFLAGS value.  These could be translated to BSD's st_flags.
> > >      Note that the Linux IOC flags are a mess and filesystems such as Ext4
> > >      define flags that aren't in linux/fs.h, so translation in the kernel
> > >      may be a necessity (or, possibly, we provide the filesystem type too).
> > 
> > And we now also have FS_IOC_FSGETXATTR that extends the flags
> > and information userspace can get from filesystems.
> 
> Btw, can you point me at the manpage that defines the fsxattr struct and its
> flags?

man xfsctl is the original source. However, ....

> Also, ioctl_list(2) should probably include FS_IOC_FS[GS]ETXATTR.

... I thought patches had been sent to Michael to document them at
the VFS ioctl level. maybe I confused it with something else.....

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available
  2016-11-18  9:43   ` David Howells
@ 2016-11-18 21:41     ` Dave Chinner
  2016-11-18 22:24     ` David Howells
  1 sibling, 0 replies; 52+ messages in thread
From: Dave Chinner @ 2016-11-18 21:41 UTC (permalink / raw)
  To: David Howells; +Cc: linux-fsdevel, linux-kernel

On Fri, Nov 18, 2016 at 09:43:38AM +0000, David Howells wrote:
> Dave Chinner <david@fromorbit.com> wrote:
> > > Fields in struct statx come in a number of classes:
> > > 
> > >  (0) stx_dev_*, stx_blksize.
> > > 
> > >      These are local system information and are always available.
> > 
> > What does stx_blksize actually mean? It's completely ambiguous in
> > stat() because we don't actually report the physical block size
> > here - we report the "minimum unit of efficient IO" that we expect
> > applications to use. Please define :P
> 
> Definition: "Same as struct stat::st_blksize".

So it is still defined as "mostly useless", then? :/

> > > The following test program can be used to test the statx system call:
> > > 
> > > 	samples/statx/test-statx.c
> > > 
> > > Just compile and run, passing it paths to the files you want to examine.
> > > The file is built automatically if CONFIG_SAMPLES is enabled.
> > 
> > Can we get xfstests written to exercise and validate all this
> > functionality, please? I'd suggest that adding xfs_io support for
> > the statx syscall would be far more useful for xfstests than a
> > standalone  test program, too. We already have equivalent stat()
> > functionality in xfs_io and that's used quite a bit in xfstests....
> 
> Feel free to write some! ;-)

No, not my job. It is the responsibility of the person added new
functionality to write the validity tests for everyone else to use.

> But I need a simple standalone test program to be able to test what I write,
> and I've no inclination to wheel out huge testsuites for an interface that
> people are still arguing about and wanting changed.

The test suite should be developed concurrently with the code. You
know, best software engineering practices and all that. Just a small
example: Darrick landed 100+ reflink related tests in xfstests
before we merged the XFS reflink functionality. And that's just for
XFS - this is something that /all filesystems/ need to work
correctly with, so it's even more important that we have tests to
verify functionality /before/ it gets merged.

Quite frankly, I think this has to be an unconditional requirement
for such generic, expandabled new syscall functionality - either we
get test coverage for it before merge, or we don't merge it. We've
demonstrated time and time again that shit doesn't work if it's not
tested and cannot be widely verified by independent filesystem
developers.

Again, I'll use the example of Darrick's reflink tests - that
exposed multiple bugs in the btrfs reflink implementation that
nobody knew existed because /they'd never been tested/. And we've
found several subtle differences in fs implementations that would
seriously confuse applications (e.g. how a range of "0 bytes" is
treated by the filesystem) as a result of adding tests to exercise
these exact semantics.

These are the sorts of issues we need test coverage to avoid, and we
need it before merge, not after.

Cheers,

Dave.

> 
> David
> 

-- 
Dave Chinner
david@fromorbit.com

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available
  2016-11-18 10:29     ` David Howells
@ 2016-11-18 21:48       ` David Howells
  -1 siblings, 0 replies; 52+ messages in thread
From: David Howells @ 2016-11-18 21:48 UTC (permalink / raw)
  To: Dave Chinner; +Cc: dhowells, linux-fsdevel, linux-kernel, linux-api

Dave Chinner <david@fromorbit.com> wrote:

> > Btw, can you point me at the manpage that defines the fsxattr struct and its
> > flags?
> 
> man xfsctl is the original source. However, ....

	warthog>man xfsctl
	No manual entry for xfsctl

This should be in the kernel manpages repo since it's kernel UAPI.

David

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available
@ 2016-11-18 21:48       ` David Howells
  0 siblings, 0 replies; 52+ messages in thread
From: David Howells @ 2016-11-18 21:48 UTC (permalink / raw)
  To: Dave Chinner
  Cc: dhowells-H+wXaHxf7aLQT0dZR+AlfA,
	linux-fsdevel-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	linux-api-u79uwXL29TY76Z2rM5mHXA

Dave Chinner <david-FqsqvQoI3Ljby3iVrkZq2A@public.gmane.org> wrote:

> > Btw, can you point me at the manpage that defines the fsxattr struct and its
> > flags?
> 
> man xfsctl is the original source. However, ....

	warthog>man xfsctl
	No manual entry for xfsctl

This should be in the kernel manpages repo since it's kernel UAPI.

David

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available
  2016-11-18  3:28     ` Andreas Dilger
@ 2016-11-18 22:07       ` Dave Chinner
  2016-11-18 22:54       ` David Howells
  1 sibling, 0 replies; 52+ messages in thread
From: Dave Chinner @ 2016-11-18 22:07 UTC (permalink / raw)
  To: Andreas Dilger; +Cc: David Howells, linux-fsdevel, linux-kernel

On Thu, Nov 17, 2016 at 08:28:57PM -0700, Andreas Dilger wrote:
> On Nov 17, 2016, at 4:40 PM, Dave Chinner <david@fromorbit.com> wrote:
> >> 
> >> Time fields are split into separate seconds and nanoseconds fields to make
> >> packing easier and the granularities can be queried with the filesystem
> >> info system call.  Note that times will be negative if before 1970; in
> >> such a case, the nanosecond fields will also be negative if not zero.
> > 
> > So what happens in ten years time when we want to support
> > femptosecond resolution in the timestamp interface? We've got to
> > change everything to 64 bit? Shouldn't we just make everything
> > timestamp related 64 bit?
> 
> Is this a serious request?  Are we going to need to multiply everything
> by 10e9 to convert to/from nanoseconds for the next 10 years on the off
> chance that we have timestamps more accurate than this in the future?

We've been stuck with the stat() interface since, what, the early
1980s? And it will still be used in 10-15 years time. That's a
/50-year lifetime/ for a syscall interface.

So it's not unreasonable to think that statx() might have a similar
lifetime. statx() is clearly intended to support >y2038 dates
cleanly, so clearly we're intending statx() to still be around in
20-25 years. And when we start thinking in those timeframes, an
increase in timestamp resoultion of at least another 10e-3 is
likely....

> > Please isolate the new interface flags completely from the FS_*_FL
> > values. We should not repeat the mistake of tying values derived
> > from filesystem specific on-disk values to a user interface.
> 
> Using the existing FS_*_FL flags as initial values is not worse than
> starting with any other arbitrary values for the flags.

Except it starts with a sparse set of flags for no good reason.
Someone comes along needed to add a new flag and wonders WTF there
are holes in the flags space, and whether it is because flags have
been removed and whether it's unsafe to use the flag space in the
holes...

New user facing APIs should be clean and neat and not carry any
unnecessary historical baggage with them....

> >> 	STATX_ATTR_NONUNIX_OWNERSHIP	File doesn't have Unixy ownership
> >> 	STATX_ATTR_HAS_ACL		File has an ACL
> > 
> > So statx will require us to do ACL lookups? i.e. instead of just
> > reading the inode to get the information, we'll also have to do
> > extended attribute lookups? That's potentially very expensive if
> > the extended attribute is not stored in the inode....
> 
> No, there is no requirement to return anything that the caller didn't
> ask for.

Applications are going to use STATX_ALL because it's simpler than
specifying 10 different flags on every statx() call and then
checking them on return.  i.e. the set/check feature flags API
sounds good until you have to write the boiler plate code it
requires time you want to stat a file...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available
@ 2016-11-18 22:17         ` Dave Chinner
  0 siblings, 0 replies; 52+ messages in thread
From: Dave Chinner @ 2016-11-18 22:17 UTC (permalink / raw)
  To: David Howells; +Cc: linux-fsdevel, linux-kernel, linux-api

On Fri, Nov 18, 2016 at 09:48:21PM +0000, David Howells wrote:
> Dave Chinner <david@fromorbit.com> wrote:
> 
> > > Btw, can you point me at the manpage that defines the fsxattr struct and its
> > > flags?
> > 
> > man xfsctl is the original source. However, ....
> 
> 	warthog>man xfsctl
> 	No manual entry for xfsctl
> 
> This should be in the kernel manpages repo since it's kernel UAPI.

"original source" is where the API came from - that's
XFS_IOC_FSGETXATTR - and xfsctl from xfsprogs is where that was
documented. That page documents a bunch of other XFS specific
ioctls, too, so it is appropriately located.

Like I said, I thought patches had been sent to Michael to lift the
FS_IOC_FSGETXATTR documentation from this page into the official
linux man pages package. If not, that can be chased up separately,
but the XFS ioctl man page certainly does not belong there.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available
@ 2016-11-18 22:17         ` Dave Chinner
  0 siblings, 0 replies; 52+ messages in thread
From: Dave Chinner @ 2016-11-18 22:17 UTC (permalink / raw)
  To: David Howells
  Cc: linux-fsdevel-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	linux-api-u79uwXL29TY76Z2rM5mHXA

On Fri, Nov 18, 2016 at 09:48:21PM +0000, David Howells wrote:
> Dave Chinner <david-FqsqvQoI3Ljby3iVrkZq2A@public.gmane.org> wrote:
> 
> > > Btw, can you point me at the manpage that defines the fsxattr struct and its
> > > flags?
> > 
> > man xfsctl is the original source. However, ....
> 
> 	warthog>man xfsctl
> 	No manual entry for xfsctl
> 
> This should be in the kernel manpages repo since it's kernel UAPI.

"original source" is where the API came from - that's
XFS_IOC_FSGETXATTR - and xfsctl from xfsprogs is where that was
documented. That page documents a bunch of other XFS specific
ioctls, too, so it is appropriately located.

Like I said, I thought patches had been sent to Michael to lift the
FS_IOC_FSGETXATTR documentation from this page into the official
linux man pages package. If not, that can be chased up separately,
but the XFS ioctl man page certainly does not belong there.

Cheers,

Dave.
-- 
Dave Chinner
david-FqsqvQoI3Ljby3iVrkZq2A@public.gmane.org

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available
  2016-11-18  9:43   ` David Howells
  2016-11-18 21:41     ` Dave Chinner
@ 2016-11-18 22:24     ` David Howells
  1 sibling, 0 replies; 52+ messages in thread
From: David Howells @ 2016-11-18 22:24 UTC (permalink / raw)
  To: Dave Chinner; +Cc: dhowells, linux-fsdevel, linux-kernel

Dave Chinner <david@fromorbit.com> wrote:

> > Definition: "Same as struct stat::st_blksize".
> 
> So it is still defined as "mostly useless", then? :/

If we're going to be able to emulate stat() with this, then st_blksize must be
determinable from whatever's in struct statx.  If you can provide something
better for stx_blksize and an algorithm for mapping that to st_blksize, then
please do so.

> The test suite should be developed concurrently with the code. You
> know, best software engineering practices and all that. Just a small
> example: Darrick landed 100+ reflink related tests in xfstests
> before we merged the XFS reflink functionality.

I can't give you tests to merge yet.  Given the amount of bikeshedding that's
taken place on this, I'm glad I *haven't* done the testsuite yet - it would
have much more than doubled the amount of work.  I *still* don't know what the
final form is going to be.  I've chucked out almost everything extra because
every bit has someone who argues with it - and this includes people who argue
against things that have to be there!

Further:

	warthog>ls xfstests-dev/doc
	CHANGES

The documentation is missing.  There's a bit in the top level README, but
there's a whole lot of information that *should* be there - and isn't.

David

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available
  2016-11-18  3:28     ` Andreas Dilger
  2016-11-18 22:07       ` Dave Chinner
@ 2016-11-18 22:54       ` David Howells
  2016-11-19 22:43         ` Dave Chinner
                           ` (2 more replies)
  1 sibling, 3 replies; 52+ messages in thread
From: David Howells @ 2016-11-18 22:54 UTC (permalink / raw)
  To: Dave Chinner; +Cc: dhowells, Andreas Dilger, linux-fsdevel, linux-kernel

Dave Chinner <david@fromorbit.com> wrote:

> And when we start thinking in those timeframes, an
> increase in timestamp resoultion of at least another 10e-3 is
> likely....

Is it, though?  To be useful, surely you have to be able to jam quite a few
instructions into a 1ns block, including memory accesses.

Rather than providing:

	struct timestamp {
		__s64 seconds;
		__s64 femtoseconds;
	};

which would require 64-bit divisions to get nanosecond timestamps that we do
actually use, I would lean towards:

	struct timestamp {
		__s64 seconds;
		__s32 nanoseconds;
		__s32 femtoseconds;
	};

where the fields are, in effect, additive.  Which means I could represent this
as:

	__s64	stx_atime_s;	/* Last access time */
	__s64	stx_btime_s;	/* File creation time */
	__s64	stx_ctime_s;	/* Last attribute change time */
	__s64	stx_mtime_s;	/* Last data modification time */
	__s32	stx_atime_ns;	/* Last access time (ns part) */
	__s32	stx_btime_ns;	/* File creation time (ns part) */
	__s32	stx_ctime_ns;	/* Last attribute change time (ns part) */
	__s32	stx_mtime_ns;	/* Last data modification time (ns part) */

and then add:

	__s32	stx_atime_fs;	/* Last access time (fs part) */
	__s32	stx_btime_fs;	/* File creation time (fs part) */
	__s32	stx_ctime_fs;	/* Last attribute change time (fs part) */
	__s32	stx_mtime_fs;	/* Last data modification time (fs part) */

later.

If we *really* do want to allow for atto- or femto- second resolution
timestamps (and you've still not entirely convinced me that it's going to be
necessary - the speed of signal propagation still has an ungetroundable
limit), then we could stick the space in now - but I think it's likely to
remain dead space.

Maybe we should switch to Windows-style timestamp resolution:

	struct timestamp {
		__s64 hundred_ns;	/* Time in 100ns increments */
		__s32 femtoseconds;	/* Additional fs component */
	};

> > Using the existing FS_*_FL flags as initial values is not worse than
> > starting with any other arbitrary values for the flags.
>
> Except it starts with a sparse set of flags for no good reason.

Actually, a very good reason.  You can map those flags, on ext4 at least, with
a load, an AND and an OR.  Three instructions[*].  If the bits don't
correspond, it gets more expensive (4-5 instructions per bit + 1).

[*] Leastways, it *should* be three instructions, but gcc fails to optimise it
    correctly.  I have a bz logged for this.

David

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available
  2016-11-18 22:17         ` Dave Chinner
  (?)
@ 2016-11-19 10:21         ` Michael Kerrisk (man-pages)
  -1 siblings, 0 replies; 52+ messages in thread
From: Michael Kerrisk (man-pages) @ 2016-11-19 10:21 UTC (permalink / raw)
  To: Dave Chinner; +Cc: David Howells, linux-fsdevel, lkml, Linux API, Li Xi

Hi Dave,

[Best to CC me when I'm mentioned in the discussion. I only caught
this by chance.]

On 18 November 2016 at 23:17, Dave Chinner <david@fromorbit.com> wrote:
> On Fri, Nov 18, 2016 at 09:48:21PM +0000, David Howells wrote:
>> Dave Chinner <david@fromorbit.com> wrote:
>>
>> > > Btw, can you point me at the manpage that defines the fsxattr struct and its
>> > > flags?
>> >
>> > man xfsctl is the original source. However, ....
>>
>>       warthog>man xfsctl
>>       No manual entry for xfsctl
>>
>> This should be in the kernel manpages repo since it's kernel UAPI.
>
> "original source" is where the API came from - that's
> XFS_IOC_FSGETXATTR - and xfsctl from xfsprogs is where that was
> documented. That page documents a bunch of other XFS specific
> ioctls, too, so it is appropriately located.
>
> Like I said, I thought patches had been sent to Michael to lift the
> FS_IOC_FSGETXATTR documentation from this page into the official
> linux man pages package. If not, that can be chased up separately,
> but the XFS ioctl man page certainly does not belong there.

No patches for FS_IOC_FSGETXATTR documentation came to man-pages, as
far as I know. I'll be happy to take them.

Cheers,

Michael

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available
  2016-11-18 22:54       ` David Howells
@ 2016-11-19 22:43         ` Dave Chinner
  2016-11-21 14:30         ` One Thousand Gnomes
  2016-11-22 10:39         ` David Howells
  2 siblings, 0 replies; 52+ messages in thread
From: Dave Chinner @ 2016-11-19 22:43 UTC (permalink / raw)
  To: David Howells; +Cc: Andreas Dilger, linux-fsdevel, linux-kernel

On Fri, Nov 18, 2016 at 10:54:02PM +0000, David Howells wrote:
> Dave Chinner <david@fromorbit.com> wrote:
> 
> > And when we start thinking in those timeframes, an
> > increase in timestamp resoultion of at least another 10e-3 is
> > likely....
> 
> Is it, though?  To be useful, surely you have to be able to jam quite a few
> instructions into a 1ns block, including memory accesses.
> 
> Rather than providing:
> 
> 	struct timestamp {
> 		__s64 seconds;
> 		__s64 femtoseconds;
> 	};
> 
> which would require 64-bit divisions to get nanosecond timestamps that we do
> actually use, I would lean towards:
> 
> 	struct timestamp {
> 		__s64 seconds;
> 		__s32 nanoseconds;
> 		__s32 femtoseconds;
> 	};

No. Just provide a 64 bit high resoultion field, and define it to
contain nanoseconds. When we need higher resolution to be exported
to userspace, we use a /feature flag/ to indicate that is contains
something like attoseconds or the like.

This also gives userspace a method of choosing the resolution it
wants.....

> 	__s32	stx_btime_ns;	/* File creation time (ns part) */
> 	__s32	stx_ctime_ns;	/* Last attribute change time (ns part) */
> 	__s32	stx_mtime_ns;	/* Last data modification time (ns part) */
> 
> and then add:
> 
> 	__s32	stx_atime_fs;	/* Last access time (fs part) */
> 	__s32	stx_btime_fs;	/* File creation time (fs part) */
> 	__s32	stx_ctime_fs;	/* Last attribute change time (fs part) */
> 	__s32	stx_mtime_fs;	/* Last data modification time (fs part) */
> 
> later.

Which burns a significant part of the spare space in the structure.

> If we *really* do want to allow for atto- or femto- second resolution
> timestamps (and you've still not entirely convinced me that it's going to be
> necessary - the speed of signal propagation still has an ungetroundable
> limit), then we could stick the space in now - but I think it's likely to
> remain dead space.

We don't really care if the strucuture 250 bytes or 300 bytes, it's
not going to have any significant impact on memory usage or
performance. We should just suck it up now and future
proof the timestamp interface, as history has proven repeatedly that
we suck as making our time/timestamp interfaces future proof....

> > > Using the existing FS_*_FL flags as initial values is not worse than
> > > starting with any other arbitrary values for the flags.
> >
> > Except it starts with a sparse set of flags for no good reason.
> 
> Actually, a very good reason.  You can map those flags, on ext4 at least, with
> a load, an AND and an OR.  Three instructions[*].  If the bits don't
> correspond, it gets more expensive (4-5 instructions per bit + 1).

Two words: premature optimisation.

Every other filesystem has to map their own internal flags to the
user interface flags, so why should we make the user interface
harder to understand and maintain just to allow a special snowflake
optimisation for /only one filesystem/?

There's a worse problem than that, though - we can't add certain
flags to the userspace API because the /conflict with ext4 on-disk
flags/ that aren't exported to userspace and so to work around that
we have this shitty hack to define what parts of the flag space
contain flags that the userspace API can interact with:

#define FS_FL_USER_VISIBLE              0x0003DFFF /* User visible flags */
#define FS_FL_USER_MODIFIABLE           0x000380FF /* User modifiable flags */

These mask out the ext2/3/4 flags that should not be visible to
userspace and/or not be modifiable by userspace. Having to maintain
crap like this is a direct result of exporting on-disk flag values
to userspace APIs.

*Let's not repeat the mistakes of the past* in new interfaces.

Cheers,

Dave.

> 
> [*] Leastways, it *should* be three instructions, but gcc fails to optimise it
>     correctly.  I have a bz logged for this.
> 
> David
> 

-- 
Dave Chinner
david@fromorbit.com

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available
  2016-11-18 22:54       ` David Howells
  2016-11-19 22:43         ` Dave Chinner
@ 2016-11-21 14:30         ` One Thousand Gnomes
  2016-11-21 20:43           ` Dave Chinner
  2016-11-22 10:39         ` David Howells
  2 siblings, 1 reply; 52+ messages in thread
From: One Thousand Gnomes @ 2016-11-21 14:30 UTC (permalink / raw)
  To: David Howells; +Cc: Dave Chinner, Andreas Dilger, linux-fsdevel, linux-kernel

> > increase in timestamp resoultion of at least another 10e-3 is
> > likely....  
> 
> Is it, though?  To be useful, surely you have to be able to jam quite a few
> instructions into a 1ns block, including memory accesses.
> 
> Rather than providing:
> 
> 	struct timestamp {
> 		__s64 seconds;
> 		__s64 femtoseconds;
> 	};
> 
> which would require 64-bit divisions to get nanosecond timestamps that we do
> actually use, I would lean towards:
> 
> 	struct timestamp {
> 		__s64 seconds;
> 		__s32 nanoseconds;
> 		__s32 femtoseconds;
> 	};

Which gets silly. The nanosecond world is defined by the speed of light.
Short of someone finding a way to change that digital computing as we
know it today is going to be living in the nanoseconds world. You hit the
point of 'can't measure the difference' before you hit the point of 'can
usefully order things using'

Alan

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available
  2016-11-21 14:30         ` One Thousand Gnomes
@ 2016-11-21 20:43           ` Dave Chinner
  0 siblings, 0 replies; 52+ messages in thread
From: Dave Chinner @ 2016-11-21 20:43 UTC (permalink / raw)
  To: One Thousand Gnomes
  Cc: David Howells, Andreas Dilger, linux-fsdevel, linux-kernel

On Mon, Nov 21, 2016 at 02:30:13PM +0000, One Thousand Gnomes wrote:
> > > increase in timestamp resoultion of at least another 10e-3 is
> > > likely....  
> > 
> > Is it, though?  To be useful, surely you have to be able to jam quite a few
> > instructions into a 1ns block, including memory accesses.
> > 
> > Rather than providing:
> > 
> > 	struct timestamp {
> > 		__s64 seconds;
> > 		__s64 femtoseconds;
> > 	};
> > 
> > which would require 64-bit divisions to get nanosecond timestamps that we do
> > actually use, I would lean towards:
> > 
> > 	struct timestamp {
> > 		__s64 seconds;
> > 		__s32 nanoseconds;
> > 		__s32 femtoseconds;
> > 	};
> 
> Which gets silly. The nanosecond world is defined by the speed of light.
> Short of someone finding a way to change that digital computing as we
> know it today is going to be living in the nanoseconds world. You hit the
> point of 'can't measure the difference' before you hit the point of 'can
> usefully order things using'

We already have clock rates that are fractions of a nanosecond per
cycle. We have pmem storage here right now that is accessed at the
speed of the CPU - actual nanosecond resolution timestamp capability
is a reality at the bleeding edge of storage technology right now.

It doesn't take much vision to extend the current hardare
capabilities with coherent hardware accelerators (e.g. as has been
added to the Power platform) writing directly into pmem storage and
providing higher resolution timestamps than the CPU can generate.

Call me silly if you want - I don't care - but let's not ignore the
emerging storage technology trends that are there for everyone to
see...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available
  2016-11-18 22:54       ` David Howells
  2016-11-19 22:43         ` Dave Chinner
  2016-11-21 14:30         ` One Thousand Gnomes
@ 2016-11-22 10:39         ` David Howells
  2016-11-22 13:55           ` Jeff Layton
  2016-11-22 20:58           ` Dave Chinner
  2 siblings, 2 replies; 52+ messages in thread
From: David Howells @ 2016-11-22 10:39 UTC (permalink / raw)
  To: Dave Chinner; +Cc: dhowells, Andreas Dilger, linux-fsdevel, linux-kernel

Dave Chinner <david@fromorbit.com> wrote:

> No. Just provide a 64 bit high resoultion field, and define it to
> contain nanoseconds. When we need higher resolution to be exported
> to userspace, we use a /feature flag/ to indicate that is contains
> something like attoseconds or the like.

That sounds suspiciously like a bad idea - if you're talking about a flag with
a currently undefined meaning that the kernel can inflict on userspace without
warning to change the meaning of the nanoseconds field to something we haven't
defined yet.

Userspace would have to ask for it.

David

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available
  2016-11-22 10:39         ` David Howells
@ 2016-11-22 13:55           ` Jeff Layton
  2016-11-22 20:58           ` Dave Chinner
  1 sibling, 0 replies; 52+ messages in thread
From: Jeff Layton @ 2016-11-22 13:55 UTC (permalink / raw)
  To: David Howells, Dave Chinner; +Cc: Andreas Dilger, linux-fsdevel, linux-kernel

On Tue, 2016-11-22 at 10:39 +0000, David Howells wrote:
> Dave Chinner <david@fromorbit.com> wrote:
> 
> > 
> > No. Just provide a 64 bit high resoultion field, and define it to
> > contain nanoseconds. When we need higher resolution to be exported
> > to userspace, we use a /feature flag/ to indicate that is contains
> > something like attoseconds or the like.
> 
> That sounds suspiciously like a bad idea - if you're talking about a flag with
> a currently undefined meaning that the kernel can inflict on userspace without
> warning to change the meaning of the nanoseconds field to something we haven't
> defined yet.
> 
> Userspace would have to ask for it.
> 

Agreed.

I think the best thing would be to simply plan to add new femtoseconds
fields in the struct if/when it becomes needed. We can easily hide the
ugliness of the fields not being adjacent to the rest of the timestamp
behind the femtosecond resolution glibc API that will also be needed.

If we're worried about space utilization, then let's pad the struct out
by 4 extra 32-bit fields in advance of that.

Again, a major design point of statx is that it is to be extendable. I
don't see any reason that we need to do this now.

-- 
Jeff Layton <jlayton@redhat.com>

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available
  2016-11-22 10:39         ` David Howells
  2016-11-22 13:55           ` Jeff Layton
@ 2016-11-22 20:58           ` Dave Chinner
  1 sibling, 0 replies; 52+ messages in thread
From: Dave Chinner @ 2016-11-22 20:58 UTC (permalink / raw)
  To: David Howells; +Cc: Andreas Dilger, linux-fsdevel, linux-kernel

On Tue, Nov 22, 2016 at 10:39:29AM +0000, David Howells wrote:
> Dave Chinner <david@fromorbit.com> wrote:
> 
> > No. Just provide a 64 bit high resoultion field, and define it to
> > contain nanoseconds. When we need higher resolution to be exported
> > to userspace, we use a /feature flag/ to indicate that is contains
> > something like attoseconds or the like.
> 
> That sounds suspiciously like a bad idea - if you're talking about a flag with
> a currently undefined meaning that the kernel can inflict on userspace without
> warning to change the meaning of the nanoseconds field to something we haven't
> defined yet.
> 
> Userspace would have to ask for it.

Yes, of course it would - this would enable userspace to move from
struct timespec to something with higher resolution without having
to use different structures or guess what the resolution being
returned by the kernel is for different filesystems,

We had a major mess with the time_t -> struct timespec upgrade of
the stat() kernel interface to support nanosecond timestamps in the
syscall because when stat() was first designed  all those years ago
single second resolution was all anyone needed. The original
designers of the stat API didn't have 30+ years of history telling
them that machines will get faster than anyone could imagine and
that timestamps will always get more accurate and increase in
resolution.

Perhaps people are fine with repeating past mistakes - all I can do
is point them out and suggest alternative approaches that will avoid
a repeat...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

^ permalink raw reply	[flat|nested] 52+ messages in thread

end of thread, other threads:[~2016-11-22 20:58 UTC | newest]

Thread overview: 52+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-11-17 13:34 [RFC][PATCH 0/4] Enhanced file stat system call David Howells
2016-11-17 13:35 ` [PATCH 1/4] statx: Add a system call to make enhanced file info available David Howells
2016-11-17 18:39   ` Jeff Layton
2016-11-18  2:32     ` Andreas Dilger
2016-11-18  8:59     ` David Howells
2016-11-18  8:59       ` David Howells
2016-11-18  9:25       ` Andreas Dilger
2016-11-18  9:25         ` Andreas Dilger
2016-11-17 23:40   ` Dave Chinner
2016-11-18  3:28     ` Andreas Dilger
2016-11-18 22:07       ` Dave Chinner
2016-11-18 22:54       ` David Howells
2016-11-19 22:43         ` Dave Chinner
2016-11-21 14:30         ` One Thousand Gnomes
2016-11-21 20:43           ` Dave Chinner
2016-11-22 10:39         ` David Howells
2016-11-22 13:55           ` Jeff Layton
2016-11-22 20:58           ` Dave Chinner
2016-11-18  9:53     ` David Howells
2016-11-18  8:48   ` David Howells
2016-11-18 12:01     ` Jeff Layton
2016-11-18  9:36   ` David Howells
2016-11-18 17:17     ` Jeff Layton
2016-11-18 18:04     ` David Howells
2016-11-18 18:54       ` Jeff Layton
2016-11-18 19:08       ` David Howells
2016-11-18  9:43   ` David Howells
2016-11-18 21:41     ` Dave Chinner
2016-11-18 22:24     ` David Howells
2016-11-18 10:29   ` David Howells
2016-11-18 10:29     ` David Howells
2016-11-18 21:27     ` Dave Chinner
2016-11-18 21:48     ` David Howells
2016-11-18 21:48       ` David Howells
2016-11-18 22:17       ` Dave Chinner
2016-11-18 22:17         ` Dave Chinner
2016-11-19 10:21         ` Michael Kerrisk (man-pages)
2016-11-17 13:35 ` [PATCH 2/4] statx: Ext4: Return enhanced file attributes David Howells
2016-11-18  3:30   ` Andreas Dilger
2016-11-17 13:35 ` [PATCH 3/4] statx: NFS: " David Howells
2016-11-17 13:35 ` [PATCH 4/4] statx: AFS: " David Howells
2016-11-18  3:34   ` Andreas Dilger
2016-11-18  8:47   ` David Howells
2016-11-17 14:39 ` [RFC][PATCH 0/4] Enhanced file stat system call One Thousand Gnomes
2016-11-17 15:10 ` Michael Kerrisk
2016-11-17 16:33 ` David Howells
2016-11-17 16:45 ` David Howells
2016-11-17 20:00   ` J. Bruce Fields
2016-11-18  2:30     ` Andreas Dilger
2016-11-18  4:29       ` NeilBrown
2016-11-18 13:41   ` One Thousand Gnomes
2016-11-18 13:49   ` David Howells

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.