[OpenAFS] Update time loses 67 seconds on new volume

[Kristen Webb]

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.

Kris
--
This message is NOT encrypted
--------------------------------
Mr. Kristen J. Webb
Chief Technology Officer
Teradactyl LLC.
2450 Baylor Dr. S.E.
Albuquerque, New Mexico 87106
Phone: [phone]
Email: ***@teradactyl.com
Web: http://www.teradactyl.com



Providers of Scalable Backup Solutions
for Unique Data Environments

--------------------------------
NOTICE TO RECIPIENTS: Any information contained in or attached to this
message is intended solely for the use of the intended recipient(s). If
you are not the intended recipient of this transmittal, you are hereby
notified that you received this transmittal in error, and we request
that you please delete and destroy all copies and attachments in your
possession, notify the sender that you have received this communication
in error, and note that any review or dissemination of, or the taking of
any action in reliance on, this communication is expressly prohibited.


Regular internet e-mail transmission cannot be guaranteed to be secure
or error-free. Therefore, we do not represent that this information is
complete or accurate, and it should not be relied upon as such. If you
prefer to communicate with Teradactyl LLC. using secure (i.e., encrypted
and/or digitally signed) e-mail transmission, please notify the sender.
Otherwise, you will be deemed to have consented to communicate with
Teradactyl via regular internet e-mail transmission. Please note that
Teradactyl reserves the right to intercept, monitor, and retain all
e-mail messages (including secure e-mail messages) sent to or from its
systems as permitted by applicable law

[Benjamin Kaduk]

Post by Kristen Webb
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
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

[Kristen Webb]

So it turns out that the files servers were backgraded during an OS
upgrade. The client is in
the process of correcting this now. I did find some additional information
from our
logs. The rw volume was unattached and the .backup volume was busy,
indicating a volume
move during our cell scan. This problem may have been already been resolved
with the changes you mentioned.

Thanks,

Kris

Post by Kristen Webb

Post by Kristen Webb
I found this situation at a client site and though it was worth brining
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

Post by Kristen Webb
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

Post by Kristen Webb
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.

Post by Kristen Webb
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

--
This message is NOT encrypted
--------------------------------
Mr. Kristen J. Webb
Chief Technology Officer
Teradactyl LLC.
2450 Baylor Dr. S.E.
Albuquerque, New Mexico 87106
Phone: [phone]
Email: ***@teradactyl.com
Web: http://www.teradactyl.com



Providers of Scalable Backup Solutions
for Unique Data Environments

--------------------------------
NOTICE TO RECIPIENTS: Any information contained in or attached to this
message is intended solely for the use of the intended recipient(s). If
you are not the intended recipient of this transmittal, you are hereby
notified that you received this transmittal in error, and we request
that you please delete and destroy all copies and attachments in your
possession, notify the sender that you have received this communication
in error, and note that any review or dissemination of, or the taking of
any action in reliance on, this communication is expressly prohibited.


Regular internet e-mail transmission cannot be guaranteed to be secure
or error-free. Therefore, we do not represent that this information is
complete or accurate, and it should not be relied upon as such. If you
prefer to communicate with Teradactyl LLC. using secure (i.e., encrypted
and/or digitally signed) e-mail transmission, please notify the sender.
Otherwise, you will be deemed to have consented to communicate with
Teradactyl via regular internet e-mail transmission. Please note that
Teradactyl reserves the right to intercept, monitor, and retain all
e-mail messages (including secure e-mail messages) sent to or from its
systems as permitted by applicable law