On Fri, 11 Mar 2011 17:21:38 +0000 Simon Wilkinson <[email protected]> wrote:
> In what circumstances would you be comparing this value with one > derived from a source with higher granularity, though? I'm really > interested in specific use cases here. We're talking about adding a > significant overhead here - I think we need to clearly understand the > benefits. Making up a notation here: 1sR100ns means '1 second after 1 Jan 1901 with 100ns resolution'. A vnode has a modification date of 1.5sR100ns. A volume on-disk structure says that we last backed up a volume at 1sR1s, because the on-disk structure only stores seconds. When recloning for a backup, we need to determine whether or not the file was modified after the last backup clone; in this case, you say 'no'. There's also the other way around, where you have a vnode modification date of 1sR1s, and a volume stored time of 1.5sR100ns. It just seems like if we need to communicate anything for the resolution information (and it really seems like we do, otherwise we always treat 1sR<anything> as 1sR1s), the resolution information needs to travel with the time data itself, because it often does not depend on the software capability of the service, but also on the capabilities of every system through which the value has passed (e.g. stored on disk in a R1s structure). > > If you transmit that time (or a time derived from it), it is > > inferred from the other side that it has 100ns granularity if this > > is done just with a per-service cap bit, which is incorrect. > > You could easily require that an implementation that advertises a > specific level of granularity provides that for all values (and rounds > down items that come from higher granularity sources) Then it sounds like a service (such as, the file service) cannot ever do anything with timestamps more granular than 1s until all on-disk structures are updated, and it doesn't accept metadata-modifying RPCs that accept 1s-timestamps. -- Andrew Deason [email protected] _______________________________________________ AFS3-standardization mailing list [email protected] http://lists.openafs.org/mailman/listinfo/afs3-standardization
