On 1/3/2019 2:54 PM, Kristen Webb wrote: > 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. >
Kris, I'm not sure what if any data corruption is taking place during volume moves with OpenAFS 1.8.x but I believe looking at the volume Copy date is a red herring. OpenAFS destroys the ".backup" as part of a RW volume move. Therefore, the "Copy" date is not expected to match the "Copy" date of the RW when the BACK is re-created. The Copy field displays the date and time this copy of this volume was created. This is the time when the volume was created on the File Server and partition from which statistics are obtained. For read/write volumes, it is the date and time of initial creation if the volume has never been moved or restored, or the date and time of the most recent move or restore operation. For read-only volumes, it is the date and time of the initial vos release command that copied the volume data to the File Server and partition. For backup volumes, it is the date and time of the initial vos backup or vos backupsys command on the specified File Server and partition. It will match the Creation field. The copy date is not stored in volume dumps and cannot be restored or migrated to another File Server or partition. Jeffrey Altman
<<attachment: jaltman.vcf>>
smime.p7s
Description: S/MIME Cryptographic Signature
