[OpenAFS] file corruption after restoring large readonly volumes

Brendan Kirby bkirby@mvista.com
Wed, 25 Aug 2004 09:48:33 -0700

On Wed, 2004-08-25 at 09:18, Jeffrey Hutzelman wrote:
> On Tuesday, August 24, 2004 19:17:15 -0700 Brendan Kirby 
> <bkirby@mvista.com> wrote:
> > Drive to remote location, hook up the drive to the other machine, then:
> > vos restore -server remote-server -partition /vicepb -name vol -id
> > vol.readonly -readonly -overwrite full < /path/to/disk/dumpfile vos
> > release vol
> This will not work, because 'vos restore -readonly' does not currently 
> create volumes which are suitable targets for later releases. 
> Particularly, it does not set the volume last-update timestamp correctly, 
> nor does it set the parent volume ID's on vnodes in the new volume.
> The first problem means that a later vos release will use an incremental 
> dump with an incorrect (too late) start time.  The result is that the RO 
> volume after the release may contain old contents for some files and 
> directories, and may contain directory entries for files whose contents are 
> not in the volume at all.
> This problem can be worked around using new functionality provided by DELTA 
> volser-restore-timestamp-cleanup-20040728, which first appeared in OpenAFS 
> 1.3.70.  This delta adds the -creation and -lastupdate switches to vos 
> restore, which control how the timestamps are generated:
>   vos restore ... -readonly -lastupdate dump
> For this to work, you must be using the new vos, and the target server must 
> be running the new volserver which supports this feature.

Unfortunately, this is a production box.  So, upgrading to the unstable
version is not something I want to do.  Thanks for the help and the
explanation.  I don't suppose just replacing volserver and vos on the
target server temporarily to do the restore would be a good idea, right?

> The second problem will be completely fatal on namei platforms (such as 
> Linux) if you ever try to move the RW volume to the site where you did the 
> manual restore.  If you don't plan on ever doing that, I believe doing the 
> restore is safe, but I don't have a whole lot of operational experience 
> with the namei fileserver.  Perhaps someone else who has investigated this 
> issue more completely will comment...

I don't plan to move the RW volume, but you never know.  If I was to
dump the RW volume, then remove it and all the replication sites.  Then,
restore the RW volume to this other machine, will this still be
completely fatal?

Thanks for your help.