[OpenAFS] Re: Restoring a RW volume that had replicas

[Andrew Deason]

On Tue, 03 Apr 2012 15:50:53 -0400
Jeff Blaine <jblaine@kickflop.net> wrote:

> There should have been no myvol (or id 12340) in the VLDB when
> the 'vos rename' ran, from what I understand.

But you still had replicas on other sites, right? If you have
'myvol.readonly' vols, then 'myvol' also exists in the vldb. Volumes
like 'myvol', 'myvol.backup', 'myvol.readonly' etc aren't really
separate entries. There is one entry in the vldb for 'myvol', and the
vlserver records the RW, RO, BK, etc volume ids for it.

I think the RW id is always set and you can't get rid of it (even if
there are no sites where the RW is present), but I'm not sure.

> > If you want to restore under the original volume name and id number,
> > 'vos restore' to 'myvol' directly with -name and -id.
> 
> Let's say I must restore to myvol.R

Well, I don't think we provide any way to change the volume id number,
and I'm not sure how feasible/advisable doing that would be, since a lot
of things can go wrong.

But you have some options. You can remove the replicas (you may need a
'vos delentry' as well; I'm not sure), then rename the volume, and add
the replicas back and release. The volume ID number will have changed,
though, and any clients using that volume will need an 'fs checkv'
before they can use it again (or wait 2 hours).

Or you can 'vos dump myvol.R | vos restore -name myvol -id <theid>'. If
you're doing this to a server that has a replica, you really want to do
it on the same partition as the extant RO (we try to prevent you from
doing otherwise, but I'm not sure if all edge cases are caught; in past
versions we have missed some). Note that when you release, this should
cause a full release, since doing a restore can screw up our tracking of
the incremental data to send, etc.

-- 
Andrew Deason
adeason@sinenomine.net