This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 1/6] xstat: Add a pair of system calls to make extendedfile stats available
- From: "J. Bruce Fields" <bfields at fieldses dot org>
- To: David Howells <dhowells at redhat dot com>
- Cc: linux-fsdevel at vger dot kernel dot org, linux-nfs at vger dot kernel dot org,linux-cifs at vger dot kernel dot org, samba-technical at lists dot samba dot org,linux-ext4 at vger dot kernel dot org, wine-devel at winehq dot org,kfm-devel at kde dot org, nautilus-list at gnome dot org,linux-api at vger dot kernel dot org, libc-alpha at sourceware dot org
- Date: Thu, 26 Apr 2012 10:23:29 -0400
- Subject: Re: [PATCH 1/6] xstat: Add a pair of system calls to make extendedfile stats available
- References: <20120424212911.GA26073@fieldses.org><20120419140558.17272.74360.stgit@warthog.procyon.org.uk><20120419140612.17272.57774.stgit@warthog.procyon.org.uk><18533.1335447617@redhat.com>
On Thu, Apr 26, 2012 at 02:40:17PM +0100, David Howells wrote:
> J. Bruce Fields <bfields@fieldses.org> wrote:
>
> > > (11) Include granularity fields in the time data to indicate the
> > > granularity of each of the times (NFSv4 time_delta) [Steve French].
> >
> > It looks like you're including this with *each* time? But surely
> > there's no filesystem with different granularity (say) for ctime than
> > for mtime.
>
> I put it in each time struct to use up the hole there. I could, I suppose,
> split tv_sec from tv_nsec to get rid of the holes and then put the granularity
> separately. That means that someone who wanted both the tv_sec and tv_nsec
> would have to fish them out separately, but that's probably okay.
>
> I could even make the granularity bigger then, to allow for the possibility of
> having a granularity >4s, but I don't know of anywhere that requires a gran >2.
>
> > Also, nfsd will want only one time_delta, not one for each time.
>
> time_delta? Is that the same as granularity?
Right, sorry, that's just the NFS word for the same thing.
So my whine here is just that most callers only want to know one number
and we're giving them three. Whatever, they can just pick one. It
feels a little ugly, but feel free to ignore my nitpicking....
(Though as Steve French asked: could we add this to statfs (or something
similar) instead?)
>
> > Note also we need to document carefully what this means: I think it
> > should be the granularity that the filesystem is capable of
> > representing, but people are sometimes surprised to find out that the
> > actual time source is usually more coarse-grained than that.
>
> Yeah, but the latter is something you may not be able to determine, and may
> indeed change over time (say someone updates the server kernel to one with a
> more fine-grained software clock). Also, for a network fs, it may depend on
> the client that happened to set that time last.
Yep, agreed, the granularity should be what the filesystem can store, we
should just make sure that statement makes it into any eventual man
pages or other documentation, since it does seem to surprise people.
--b.