[AFS3-std] A call for consensus on draft-deason-afs3-type-time-02

[Simon Wilkinson]

On 28 Jul 2011, at 15:51, Tony D'Amato wrote:
>=20
> 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.