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

[Jeffrey Altman]

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

On 7/28/2011 10:00 AM, Steven Jenkins wrote:
> On Wed, Jul 27, 2011 at 11:34 PM, Matt W. Benjamin <matt@linuxbox.com> =
wrote:
>> Hi Steven,
>>
>> It seems as if the natural interop scenarios with NFSv4 involve conver=
ting from a common (e.g., lfs) time representation.  What am I missing?
>=20
> 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?
>=20
> 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.
>=20
> 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.



--------------enigF78368CA6486C2DC10198171
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)

iQEcBAEBAgAGBQJOMW/mAAoJENxm1CNJffh4RjgH/jmURE2oKAFKplaF5562Wauv
G2+MirSVbbWHjiPdRonizHm1fZdyCwUcmrnVq0Z0DAymuo1jK7fLbYPD2y+tZ8OX
rFOhfLf1IKA4ElIqDc0kZ/lMiXyBIOyt2jgEu4yU9M881C1qhRDVl8xlU8Qwla3m
Eej+vZHIziUSErRBrd5X/3NLDJpeDwpaTvzWHJRynWGKzCQDokslDad98EyD+3Dq
svHAoIbHHU+0w6GgAQYLLUTFfDShQo0PK4I8voUXUr6XfKua1XJz4u4a6C3R1QHS
+Ab2Ghm3CWFb8v/CxcnULDyBTR51x7irXBVVrAh5OGMRwvOh41cFF1Ckru+8igA=
=lCDV
-----END PGP SIGNATURE-----

--------------enigF78368CA6486C2DC10198171--