On 7/28/2011 10:00 AM, Steven Jenkins wrote: > On Wed, Jul 27, 2011 at 11:34 PM, Matt W. Benjamin <[email protected]> wrote: >> Hi Steven, >> >> It seems as if the natural interop scenarios with NFSv4 involve converting >> from a common (e.g., lfs) time representation. What am I missing? > > I don't know that all interactions would be from a common local > filesystem; for example, what if someone wanted to put AFS on top of > NFSv4? > > Also, staying with the main goals of the proposal: i.e., that higher > levels of granularity for time are available and that the additional > information can be useful to various components in AFS, then if other > filesystems already have finer levels of granularity than what is > proposed, then the proposed RFC is already out of date, as a > replacement RFC would need to be done to increase the level of > granularity yet again. > > i.e., we should future proof this proposal by taking the finest level > of granularity in existing filesystems.
There have been face to face discussions surrounding the fact that the underlying ZFS time is 128-bit and could in theory represent very fine grained times that would not be representable in AFS. It was concluded that it was fine because the reality is that today there is nothing that we are aware of that is capable of generating timestamps with a precision close to the granularity that can be stored. In the face to face discussions we were much more concerned with the growth in the RPC message sizes caused by the jump in size of an AFSTime as compared to an afs_int32. I personally do not see there being much need for AFS in this round of RPC updates to support better than 100ns unless a real world environment that can generate such values is demonstrated.
signature.asc
Description: OpenPGP digital signature
