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

Jeffrey Altman jaltman@secure-endpoints.com
Thu, 28 Jul 2011 10:09:39 -0400


This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig5D9D70F367447053662767D3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 7/28/2011 9:52 AM, Steven Jenkins wrote:
> On Wed, Jul 27, 2011 at 8:32 PM, Derrick Brashear <shadow@gmail.com> wr=
ote:
> ...
>>>
>>> The seconds are the usual number of seconds since epoch, and the
>>> nseconds is the offset based on the seconds in nanoseconds.  If the
>>> proposed draft is accepted, when converting to proposed AFS timestamp=
s
>>> from NFSv4 timestamps, information would be lost.
>>
>> I disagree that we should devote the extra bits on the wire to
>> preserve this extra
>> information in the many cases a timestamp will appear on the wire
>> given how few will
>> have this extra information to "lose".
>=20
> If the goal is to preserve underlying time information at a level so
> that precision is not lost, then we need that precision.  If there is
> a better way to preserve timestamp information at the level of
> granularity of a nanosecond, please feel free to suggest something.

File systems do not copy this information to each other directly.  All
metadata is copied through an operating system VFS layer.  Are there any
VFS layers that actually provide better than 100ns resolution?

> I was concerned that bringing this up would be rehashing old
> arguments, but I was unable to find any discussion of this in the
> afs3-standardization mailing list archives.
>=20
> If those old archives are available in a public fashion somewhere, I
> would be happy to review those before commenting further on this
> section of the proposal.

I don't know how much of this debate took place on the mailing list.
The AFS time discussion goes back many years with discussions at three
hackathons:

  * Google (with regards to portable time interfaces)

  * Edinburgh (where the first draft proposal was discussed)

  * Pittsburgh (where the contents of Andrew's draft were debated
    as part of the RPC refresh work.)

Jeffrey Altman


--------------enig5D9D70F367447053662767D3
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iQEcBAEBAgAGBQJOMW2pAAoJENxm1CNJffh4TSsH/jWyCvW7eI8uoIwfSJY1WIL3
Asj6+THqWbQooe6Dtz5B5ARpzyHKQRdkJYSmY6Y50N4bXvcnAeSjktmYkQ8FHvD1
N98Nju9cKVEQ3MNT71m5k8Nm9NBU+VfPPzABa8qOuDz093C5f1+TJZQJuMhZSuEb
3llrWL4c7mQTrDCLGo4TfyIYIR1njCBx3gL3XEBo+OKPvC2TVnOHkC9zfvtpWEST
xwXB+HSS5J5kayN51gQMvUbjvcmDh7//BAtZRhbLhiXoZbVeVq/uaH5g4aPgJxNd
Mk0EVXywIm6+bmIq67cafK6FiIOUUjOKa2JVjYlEG/WZBysan6SW7FM7nGn3ZQc=
=2k0Q
-----END PGP SIGNATURE-----

--------------enig5D9D70F367447053662767D3--