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

[Andrew Deason]

On Fri, 11 Mar 2011 13:07:34 -0500
Jeffrey Altman <jaltman@secure-endpoints.com> wrote:

> > True. In such cases the only thing that I see that can be done is
> > that you flatten everything to some guessed resolution and say "it
> > works up to 1ms; good enough". But right now in the existing draft,
> > this determination is made by whomever generates the timestamp,
> > which definitely does not seem correct.
> > 
> > What about a representation for "unknown resolution"? Just, say,
> > 0xffffffff in the resolution field (or perhaps 0x00000000) means "I
> > don't know the resolution". We could cap that to mean "at most 1s
> > resolution", since I don't think anything less granular than that is
> > too common or reasonable (and we do 1s granularity right now anyway,
> > so...)
> 
> Every NTFS file timestamp on Windows is 100ns resolution.
> ZFS has micro-second resolution.
> 
> These discussions have to be held outside of the context of the OpenAFS
> implementation.  I realize that is the only implementation that you work
> on but its not the only implementation of these protocols.

I know. I'm not sure what the quoted text has to do with OpenAFS....?

> OpenAFS is going to have to modify its on-disk data structures to make
> use of 100ns resolution.  It needs to do that anyway because the
> existing on-disk representation can't handle 64-bit values correctly
> in any case.

Yes...? I don't see where you're going with this.

We are likely going to have servers that can handle 100ns time but have
data stores that do not. This doesn't even have to do with the
capabilities of the OpenAFS on-disk format; existing data stored right
now only has 1s granularity, because that's all the existing wire
protocol supports. So, no matter what the current storage format is, a
server will/can read from disk time values of 1s resolution, and may
receive e.g. volume dumps containing 1s resolution, etc etc.

-- 
Andrew Deason
adeason@sinenomine.net