[AFS3-std] Re: AFS-3 64-bit time I-D

[Andrew Deason]

On Fri, 11 Mar 2011 17:21:38 +0000
Simon Wilkinson <simon@sxw.org.uk> 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
adeason@sinenomine.net