On Fri, 11 Mar 2011 11:47:39 -0600 Andrew Deason <[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. 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 [email protected] _______________________________________________ AFS3-standardization mailing list [email protected] http://lists.openafs.org/mailman/listinfo/afs3-standardization
