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 _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
