linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Steve French <smfrench@gmail.com>
To: David Howells <dhowells@redhat.com>
Cc: viro@zeniv.linux.org.uk, jlayton@redhat.com, mcao@us.ibm.com,
	aneesh.kumar@linux.vnet.ibm.com, linux-cifs@vger.kernel.org,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	samba-technical@lists.samba.org, sjayaraman@suse.de,
	linux-ext4@vger.kernel.org
Subject: Re: [PATCH 0/3] Extended file stat functions
Date: Tue, 29 Jun 2010 15:23:07 -0500	[thread overview]
Message-ID: <AANLkTimIh9ZAasPnN5xxGxbupwkct7UihHcMe26r-MD7@mail.gmail.com> (raw)
In-Reply-To: <20100629200259.23196.81509.stgit@warthog.procyon.org.uk>

On Tue, Jun 29, 2010 at 3:02 PM, David Howells <dhowells@redhat.com> wrote:
> Implement a pair of new system calls to provide extended and further extensible
> stat functions.
>
> The third of the associated patches provides these new system calls:
>
>        struct xstat_dev {
>                unsigned int    major;
>                unsigned int    minor;
>        };
>
>        struct xstat_time {
>                unsigned long long      tv_sec;
>                unsigned long long      tv_nsec;
>        };
>
>        struct xstat {
>                unsigned int            struct_version;
>        #define XSTAT_STRUCT_VERSION    0
>                unsigned int            st_mode;
>                unsigned int            st_nlink;
>                unsigned int            st_uid;
>                unsigned int            st_gid;
>                unsigned int            st_blksize;
>                struct xstat_dev        st_rdev;
>                struct xstat_dev        st_dev;
>                unsigned long long      st_ino;
>                unsigned long long      st_size;
>                struct xstat_time       st_atime;
>                struct xstat_time       st_mtime;
>                struct xstat_time       st_ctime;
>                struct xstat_time       st_crtime;
>                unsigned long long      st_blocks;
>                unsigned long long      st_inode_version;
>                unsigned long long      st_data_version;
>                unsigned long long      query_flags;
>        #define XSTAT_QUERY_CREATION_TIME       0x00000001ULL
>        #define XSTAT_QUERY_INODE_VERSION       0x00000002ULL
>        #define XSTAT_QUERY_DATA_VERSION        0x00000004ULL
>                unsigned long long      extra_results[0];
>        };
>
>        ssize_t ret = xstat(int dfd,
>                            const char *filename,
>                            unsigned atflag,
>                            struct xstat *buffer,
>                            size_t buflen);
>
>        ssize_t ret = fxstat(int fd,
>                             struct xstat *buffer,
>                             size_t buflen);
>
> which are more fully documented in that patch's description.
>
> The bonuses of these new stat functions are:
>
>  (1) The fields in the xstat struct are cleaned up.  There are no split or
>     duplicated fields.
>
>  (2) Some extra information is made available (file creation time, inode
>     version number and data version number) where provided by the underlying
>     filesystem.
>
>     These are implemented here for Ext4 and AFS, but could also be provided
>     for CIFS, NTFS and BtrFS and probably others.

NFSv4 protocol also has a "recommended attribute" for create time that servers
should return if possible (which presumably now it would be possible to return
for Linux servers)

   time_create         50   nfstime4       R/W      The time of
creation of the object.

SMB2 protocol also returns the equivalent.

>  (3) The structure is versioned and extensible, meaning that further new system
>     calls shouldn't be required.

How does a fs return an "unknown" value for one
(e.g. version field) ... 0  or -1  or ...


>  (2) What extra bits of information might we like to see available through the
>     stat interface?  Security labels?  NFS file IDs?  Xattrs?

The list of mandatory ones for NFS is fairly small, the list of recommended
one for NFSv4 is larger (see page 44ff of
http://www.ietf.org/rfc/rfc3530.txt e.g.)

One hole that this reminded me about is how to return the superblock
time granularity (for NFSv4 this is attribute 51 "time_delta" which
is called on a superblock not on a file).  We run into time rounding
issues with Samba too.

>
>  (4) Should the inode number and data version number fields be 128-bit?
This is tricky for SMB2, if you can also provide a device id (or an object id of
some sort for the superblock) then 64 bit inode number is ok.


-- 
Thanks,

Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  parent reply	other threads:[~2010-06-29 20:23 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-29 20:02 [PATCH 0/3] Extended file stat functions David Howells
2010-06-29 20:03 ` [PATCH 1/3] Mark arguments to certain syscalls as being const David Howells
2010-06-29 20:03 ` [PATCH 2/3] AFS: Use i_generation not i_version for the vnode uniquifier David Howells
2010-06-29 20:23 ` Steve French [this message]
     [not found] ` <20100629200259.23196.81509.stgit-S6HVgzuS8uM4Awkfq6JHfwNdhmdF6hFW@public.gmane.org>
2010-06-29 20:03   ` [PATCH 3/3] Add a pair of system calls to make extended file stats available David Howells
     [not found]     ` <20100629200315.23196.68742.stgit-S6HVgzuS8uM4Awkfq6JHfwNdhmdF6hFW@public.gmane.org>
2010-06-29 22:13       ` Ulrich Drepper
     [not found]         ` <AANLkTimSU_pCXW5zR8__Q3-fzgxwEUX8rPqLeZtPD_hX-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2010-06-29 22:33           ` Steve French
2010-06-29 22:36         ` David Howells
     [not found]           ` <26026.1277851016-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2010-06-29 22:48             ` Joel Becker
2010-06-29 22:48           ` Sage Weil
     [not found]           ` <20100629224844.GF4150-0Ol/1UON5C7fiIqoQl7HmA@public.gmane.org>
2010-06-29 23:29             ` David Howells
     [not found]               ` <32322.1277854192-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2010-07-01  1:12                 ` Joel Becker
2010-06-30  8:20       ` Arnd Bergmann
2010-06-30  8:59         ` David Howells
2010-06-29 20:28   ` [PATCH 0/3] Extended file stat functions Trond Myklebust
2010-06-29 20:50     ` David Howells
     [not found] ` <AANLkTimIh9ZAasPnN5xxGxbupwkct7UihHcMe26r-MD7-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2010-06-29 20:41   ` David Howells
2010-06-29 21:07 ` Bernd Schubert
     [not found] ` <201006292307.42440.bernd.schubert-97jfqw80gc6171pxa8y+qA@public.gmane.org>
2010-06-29 21:11   ` David Howells
     [not found]     ` <24517.1277845879-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2010-06-29 21:24       ` Bernd Schubert
2010-06-29 21:28         ` David Howells
2010-06-29 21:53           ` Bernd Schubert
2010-06-29 22:59           ` Maciej W. Rozycki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=AANLkTimIh9ZAasPnN5xxGxbupwkct7UihHcMe26r-MD7@mail.gmail.com \
    --to=smfrench@gmail.com \
    --cc=aneesh.kumar@linux.vnet.ibm.com \
    --cc=dhowells@redhat.com \
    --cc=jlayton@redhat.com \
    --cc=linux-cifs@vger.kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mcao@us.ibm.com \
    --cc=samba-technical@lists.samba.org \
    --cc=sjayaraman@suse.de \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).