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

[Andrew Deason]

On Fri, 29 Jul 2011 12:44:30 -0400
Steven Jenkins <steven.jenkins@gmail.com> wrote:

> 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)

This isn't really an analagous example, since as far as I know, you
can't actually manipulate the ns part of that timestamp, as there is no
interface on Linux to set or get a timestamp with nanosecond resolution.

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

I think it's clear to everyone involved that having 1-ns resolution is
beneficial; we are aware of why you want to have them. And so, if there
were no downside to using 1-ns timestamps, we would all agree with you
without question. But the question is whether or not it is sufficiently
beneficial to make up for the downsides of widening the time fields,
since time fields show up a _lot_ in current-era AFS traffic, and so
widening them will nontrivially increase the number of bits we need to
move. I don't believe we have heard any convincing arguments directly
comparing those two costs.

The fact that systems _exist_ which can, in theory, make use of 1-ns
timestamp resolution does not automatically mean that we must also use
1-ns resolution. So far the only examples that have been provided are
z/OS, a platform for which no AFS implementations exist that I know of,
and NFSv4, which, practically speaking, will not see 1-ns timestamps in
file metadata unless interacting with a VFS layer that also supports
them.

These examples don't seem particularly useful to me, since even if they
did not exist, userland APIs to access AFS could always utilize 1-ns
resolution if we wanted. The examples of z/OS and NFSv4 interacting with
AFS do not seem any more likely than userland applications accessing AFS
(that is, both are rare), so the question is not really about what other
systems use 1-ns timestamps, but how useful 1-ns timestamps really are
to other systems.

I myself find it hard to believe that an implementation of any AFS-using
system would be significantly constrained or even prohibited from
functioning due to the 100-ns limitation, but that's just my opinion. I
don't feel very strongly about it, but I haven't heard a lot of
arguments for the opposing side about why these would actually be useful
(beyond "other systems have the ability"), or under what circumstances
we would actually rev the protocol again to handle them. The demand for
even going to sub-1s granularity at all so far has not been all that
high.

-- 
Andrew Deason
adeason@sinenomine.net