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

[Derrick Brashear]

On Mon, Aug 1, 2011 at 4:16 PM, Tom Keiser <tkeiser@sinenomine.net> wrote:
> On Mon, Aug 1, 2011 at 1:53 PM, Andrew Deason <adeason@sinenomine.net> wr=
ote:
>> On Mon, 1 Aug 2011 13:32:46 -0400
>> Derrick Brashear <shadow@gmail.com> wrote:
>>
>>> On Mon, Aug 1, 2011 at 1:28 PM, Andrew Deason <adeason@sinenomine.net> =
wrote:
>>>
>>> >> b) the granularity
>>> >
>>> > This one I still have no idea on. I see reasons for both sides.
>>>
>>> So is there a reason an extended union with the various stamp
>>> granularities would be a nonstarter? In particular I'd suggest the
>>> draft strongly discourage
>>> sending a larger timestamp than actual information supports (e.g.
>>> don't use bits to send precision you don't have, rather than
>>> trailing-zero-padding a
>>> larger than needed number)
>>
>> Well, the objection to just having 64-bit seconds and 32-bit nanoseconds
>> is "space", and a union tag is an extra 32 bits... If we had a "100 NS
>> granularity" tag, then we'd have 100-ns granularity in 96 bits, whereas
>> now we could have 1-ns granularity in 96 bits. Unless there's some other
>> scheme you're thinking of that somehow makes this more efficient?
>>
>
> This is why in Pittsburgh we proposed that overarching structures
> (e.g., AFSFetchStatus, and AFSStoreStatus) should be wrapped in
> ext-union, while proscribing the use of union/ext-union for individual
> members of those structures. =A0As I suggested last Friday, we could
> define two different AFSFetchStatus/AFSStoreStatus implied legs for
> now: one with 64-bit time, and a second with 96-bit time (perhaps, we
> would also want to define a third leg with 32-bit time--given that
> we're likely to have implementations of the protocol long before
> server backing stores can handle the increased resolution)...

and this approach would be fine for this, at least for a long time in
the interim.