[AFS3-std] Re: AFS-3 64-bit time I-D

[Andrew Deason]

On Fri, 11 Mar 2011 10:53:20 -0500
Jeffrey Altman <jaltman@secure-endpoints.com> wrote:

> Another question surrounding the resolution field is what granularity
> would be assumed when reading a timestamp out of a non-AFS file system
> that provides for 100-ns or better time granularity but no resolution
> information about the source of the value.

Yes, it seems like we need some text at least recommending what do to in
such a situation where you have nothing to go on for resolution, but I'm
not sure what. The granularity could be guessed based on whether it is a
multiple of some value, or we could specify some default.

> Thinking about it further.  Perhaps we simply need to specify that all
> values must be rounded down to the known granularity when setting the
> value and drop the resolution field.

But that makes e.g. these two times indistinguishable:

X: timestamp 1s 0ns after 1 Jan 1901 midnight, 1s-resolution
Y: timestamp 1s 0ns after 1 Jan 1901 midnight, 100ns-resolution

If you have another event that happens at

Z: timestamp 1.5s 0ns after 1 Jan 1901 midnight, 100ns-resolution

We know that Z occurs after Y, but may not occur after X. So X and Y
need to be distinguishable.

> I would be interested in hearing the use cases this is intended to
> address.

There's the obvious initial difference where the code does/doesn't
support time with more granularity than 1s, but there's more than that.
Depending on the platform we're running on, our time source may have
different resolution, and if we receive time values from some other
source (such as disk), the resolution may vary. To be conservative in
calculating when events happen in a certain order, we need to know the
earliest and latest that an event may have occurred (since we may be
calculating whether something happened before event X, or after event
X). So, I don't think we can simply it down to a single timestamp.

-- 
Andrew Deason
adeason@sinenomine.net