Add a pair of system calls to make extended file stats available
in [Kernel]
|
Prev: Hypervisor detection from within a Linux VM
Next: Fwd: fs/exec.c core dumping on NFS mounted directory
From: Ulrich Drepper on 29 Jun 2010 18:20 On Tue, Jun 29, 2010 at 13:03, David Howells <dhowells(a)redhat.com> wrote: > Add a pair of system calls to make extended file stats available, including > file creation time, inode version and data version where available through the > underlying filesystem: If you add something like this you might want to integrate another extension. This has been discussed a long time ago. In almost no situation all the information is needed. Some of the pieces of information returned by the syscall might be harder to collect than other. It makes sense in such a situation to allow the caller to specify what she is interested in. A bitmask of some sort. This was brought up by the HPC people with gigantic filesystems. For this the syscall interface should have a parameter to specify what is requested and the stat-like structure should have a field specifying what is actually present. The latter bitmask must be a superset of the former. Previous discussions centered around reusing the stat data structure and somehow make it work. But no clean solution was found. If a new structure is added anyway this could solve the issue. And while you're at it, maybe some spare fields at the end are nice. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Steve French on 29 Jun 2010 18:40
On Tue, Jun 29, 2010 at 5:13 PM, Ulrich Drepper <drepper(a)gmail.com> wrote: > On Tue, Jun 29, 2010 at 13:03, David Howells <dhowells(a)redhat.com> wrote: >> Add a pair of system calls to make extended file stats available, including >> file creation time, inode version and data version where available through the >> underlying filesystem: > > If you add something like this you might want to integrate another > extension. �This has been discussed a long time ago. �In almost no > situation all the information is needed. �Some of the pieces of > information returned by the syscall might be harder to collect than > other. �It makes sense in such a situation to allow the caller to > specify what she is interested in. �A bitmask of some sort. �This was > brought up by the HPC people with gigantic filesystems. > > For this the syscall interface should have a parameter to specify what > is requested and the stat-like structure should have a field > specifying what is actually present. �The latter bitmask must be a > superset of the former. > > Previous discussions centered around reusing the stat data structure > and somehow make it work. �But no clean solution was found. �If a new > structure is added anyway this could solve the issue. That makes sense, especially for network file systems. NFSv4 protocol spec anticipates that: "With the NFS version 4 protocol, the client is able query what attributes the server supports and construct requests with only those supported attributes (or a subset thereof)." and we were talking about something similar for SMB2 Unix Extensions (posix extensions) at the last plugfest (for SMB2 kernel client to Samba) and testing events. -- Thanks, Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |