On 28 Jul 2011, at 15:51, Tony D'Amato wrote: > > After reading the draft, and based upon the issues that Russ and Steven > brought up concerning NFSv4 interop and the epoch representation, I do not > support the draft in it's current form.
So, these would appear to be the two issues here, and I think it's worth considering them separately 1/ Time grandularity (aka NFSv4 interop) I think it's important to remember here that AFS on the wire is very different from NFSv4 on the wire, and that the choices they made aren't necessarily a good guide for the choices we should make. In particular, we transmit a FetchStatus structure with the results from practically every RPC. Unnecessary bloat in the FetchStatus structure can have significant effects on the amount of data transmission required to do AFS file operations, and on the speed of those operations. There are currently two time fields in this response. We're already adding 64bits to this structure to support extended time, adding nano-second granularity would require a further 64bits on top of this. I'd really like to see examples of shipping operating systems which expose nano-second time to the user through the VFS layer. Without examples of this, I can't see any point in adding the additional bloat. 2/ Choice of Epoch Russ makes some very good points about the dangers of using the MS Windows epoch. Given that the epoch is an arbitrary choice, I do wonder if it might be easier and safer to keep the Unix epoch for the new time type. Cheers, Simon. _______________________________________________ AFS3-standardization mailing list [email protected] http://lists.openafs.org/mailman/listinfo/afs3-standardization
