On 3/11/2011 12:54 PM, Andrew Deason wrote: > On Fri, 11 Mar 2011 12:30:05 -0500 > Jeffrey Altman <[email protected]> wrote: > >> My point is that it is impossible to know the granularity in this >> case. Transmitting additional granularity information doesn't help >> when it is unknown. > > 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. 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. However, that is independent of this document and the wire protocol. A decision to treat all values as having 1s granularity is an implementation decision based upon its capabilities. Jeffrey Altman
signature.asc
Description: OpenPGP digital signature
