On Mon, Aug 1, 2011 at 4:16 PM, Tom Keiser <[email protected]> wrote: > On Mon, Aug 1, 2011 at 1:53 PM, Andrew Deason <[email protected]> wrote: >> On Mon, 1 Aug 2011 13:32:46 -0400 >> Derrick Brashear <[email protected]> wrote: >> >>> On Mon, Aug 1, 2011 at 1:28 PM, Andrew Deason <[email protected]> >>> 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. As 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. _______________________________________________ AFS3-standardization mailing list [email protected] http://lists.openafs.org/mailman/listinfo/afs3-standardization
