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

[Andrew Deason]

On Fri, 11 Mar 2011 11:47:39 -0600
Andrew Deason <adeason@sinenomine.net> 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.

However, after writing this, I realize this is probably not at all
useful for user-visible/user-set stuff, like the file mtime, since we
don't decide event ordering based on that. And since *FetchStatus calls
are a large amount of traffic, it makes sense to reduce the overhead
there, perhaps... Maybe another type without resolution information is
needed, hmm...

-- 
Andrew Deason
adeason@sinenomine.net