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

[Tom Keiser]

On Fri, Jul 29, 2011 at 2:51 PM, Andrew Deason <adeason@sinenomine.net> wrote:
> On Fri, 29 Jul 2011 11:29:45 -0700
> Russ Allbery <rra@stanford.edu> wrote:
>
>> Andrew Deason <adeason@sinenomine.net> writes:
>>
>> > 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.
>>
>> utimensat(2) as of Linux 2.6.22.
>
> Okay, so the Linux VFS layer does have this, and it looks like at least
> Solaris 10/11 do, too. Perhaps more importantly, this appears to be in
> POSIX (or SuS or X/Open or whatever):
> <http://pubs.opengroup.org/onlinepubs/9699919799/functions/futimens.html>
> so if other Unix doesn't already have it, they probably will within the
> forseeable future.
>
> While I'm sure POSIX doesn't require actually having 1-ns resolution
> (the _POSIX_TIMESTAMP_RESOLUTION pathconf lets us say what it actually
> is), that does indicate such interfaces are/will be rather widespread
> soon enough.
>

Hmm.  This is a thorny trade-off...

While I'd like to say 1-ns resolution is going to be the best we'll
ever need, let's face it: semiconductor physics has a way of catching
us by surprise every few years.  Someday, someone is going to
standardize a picosecond-resolution time type, and we're going to be
right back where we started.  Let's admit that we can't reasonably
prescribe one fundamental time quantum (and consequent bit width) to
"rule them all" in perpetuity.  I think this has a few implications:

1) there is no "right" time-stamp resolution--we must place a
metaphorical stake in the ground at some resolution based upon
cost/benefit analysis, and subsequently use our established protocol
revision process once it becomes apparent the current resolution is no
longer sufficient
2) the types in this draft should have a "64" suffix to make it clear
that new types will come down the pipeline some day in the future.
3) all of our upper-layer RPC changes should be designed and worded in
full cognizance that time types will evolve (e.g., new AFSFetchStatus
ext-union legs with higher-resolution time types should be expected)

Remaining question: should we standardize two time resolutions (e.g.,
AFS{Abs,Rel}Time[Res]64, and AFS{Abs,Rel}Time[Res]96) at present?

Personally, I do not want to see 96-bit time be the default.  However,
I have no strong opinion either way regarding parallel standardization
of 96-bit time (and additional AFSFetchStatus ext-union legs that
embed 96-bit time types).

Cheers,

-Tom