This is an old issue that is cropping up in a different way, so I wanted to share this before I attempt to perform any sort of repair that might lose state.
A client moved a volume and currently the .backup volume copy date does not match the rw volume copy date. As far as I can tell, the version of openafs was 1.8.2 (I am confirming this now). Here are some current time stamps: # vos ex test.volume Copy Thu Nov 29 15:10:47 2018 # vos ex test.volume.backup Copy Fri Nov 30 02:38:44 2018 When I try to manually update the .backup volume the Copy time is unchanged and still different from the rw volume. My next step is to remove the .backup volume and recreate it. This may or may not correct the issue. Is there anything else we can gather about this situation that may help diagnose the issue? Also, the way this was picked up is our backup process reported some files as missing. It is interesting to note that the timestamp on the files fluctuated around the time of the copy as well: a. Currently the vnode/uniq for index has a time stamp of: FILE 5224 Wed May 23 13:27:15 2018 index b. The last full backup (note, this was a new network full taken just after the move operation, about 4:00 a.m. the next day) FILE 5224 Thu Nov 29 15:46:33 2018 index c. From a previous full backup taken before the move the timestamp is the same as it is currently FILE 5224 Wed May 23 13:27:15 2018 index Kris On Fri, Aug 10, 2018 at 4:49 PM Benjamin Kaduk <ka...@mit.edu> wrote: > 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 > -- This message is NOT encrypted -------------------------------- Mr. Kristen J. Webb Chief Technology Officer Teradactyl LLC. 2450 Baylor Dr. S.E. Albuquerque, New Mexico 87106 Phone: 1-505-338-6000 Email: kw...@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