[OpenAFS] Update time loses 67 seconds on new volume

[Benjamin Kaduk]

On Fri, Aug 10, 2018 at 02:21:19PM -0600, Kristen Webb wrote:
> I found this situation at a client site and though it was worth brining up:
> 
> The client is running openafs 1.8.0-1~ppa0~ubuntu14.04.1-debian, but
> I cannot yet vouch for the server versions.
> 
> This is a new volume and here are some times from vos exa
> 
>     Creation    Thu Aug  9 09:21:40 2018
>     Copy        Fri Aug 10 09:58:29 2018
>     Backup      Fri Aug 10 10:31:08 2018
>     Last Access Fri Aug 10 14:38:59 2018
>     Last Update Thu Aug  9 18:29:23 2018
> 
> Last night, our parts generator for afs took a snapshot of the vldb/file
> servers
> about 11:15 p.m. and reported a more recent update time for the volume on a
> different file server:
> 
> Thu Aug  9 18:30:30 2018
> 
> Which is, interestingly, 67 seconds into the future.
> 
> I noted that the volume was copied this a.m. but after the parts generator
> ran and
> after our software noticed the discrepancy about 6:00 a.m. this morning.
> 
> I have not confirmed if the volume was copied some time earlier.
> 
> The volume is about 200GB.
> 
> I'm curious if there is a reasonable explanation for this type of behavior.
> I do not recall ever catching something like this before.  I am currently
> mining our archive logs to see if I can find another instance.

The server version is probably relevant; we did make some changes in this
area for 1.8, such as modifying updateDate after salvage, and preserving
more timestamps across volume-level operations (things like
restore/clone/etc., though I forget the details offhand).

-Ben