[AFS3-std] Re: A call for consensus on draft-deason-afs3-type-time-02

[Steven Jenkins]

On Fri, Jul 29, 2011 at 12:22 PM, Andrew Deason <adeason@sinenomine.net> wr=
ote:
> On Thu, 28 Jul 2011 10:09:39 -0400
> Jeffrey Altman <jaltman@secure-endpoints.com> wrote:
>
>> File systems do not copy this information to each other directly. =A0All
>> metadata is copied through an operating system VFS layer. =A0Are there
>> any VFS layers that actually provide better than 100ns resolution?
>
> I've been told verbally (informally) that z/OS offers ns-granular
> timestamp information. I can't find documentation confirming that, but
> I'm not really sure where to look, either.
>
> It's also not strictly true that we always go through a VFS layer, since
> we could be translating directly to/from NFS, or there could be a
> userspace application that speaks those protocols directly. Going
> through an OS VFS is certainly the vast vast majority of cases, though.
>
> I'm not saying that means we care, but I believe those are some cases
> where we would lose precision.
>

I agree that most accesses are done via the VFS layer. However,
filesystems are starting to appear that have higher resolution time,
and it is only natural for applications to take advantage of this
infromation.

As an additional example beyond NFSv4 and z/OS,  Btrfs, which has been
shipping with Linux kernels for over a year, defines the following for
times (i.e., ctime, atime, mtime)

struct btrfs_timespec {
  __le64 sec;
  __le32 nsec;
} __attribute__ ((__packed__));

Since we are going to the effort now to define hi-resolution time for
OpenAFS, it seems better to do this once, rather than do a
specification for 100ns time resolution now, and another higher
resolution specification in the future which will then leave us with
two high-res times, or a need to do a migration.

Steven