[OpenAFS] AFS outage, impact of "moving" root.cell.readonly, root.afs.readonly

[Jeff Blaine]

>> 'vos remove' performs the appropriate VLDB deletion
>> for replicas just as it does for RWs.
> 
> Really?

Really

> I have had problems with a straight vos remove of a readonly not
> actually working the way it should.

You should report these at least to the list them, because
you absolutely should not be having problems with it.

With volume 'volname', RW on server1:partition-X, and 2
replicas (one on server1:partition-X and one on
server2:partition-Y), the correct way to remove the
volume and its replicas from existence is:

   vos remove server1 partition-X volname.readonly
   vos remove server2 partition-Y volname.readonly
   vos remove server1 partition-X volname

Or, if you just wanted to remove the replica on
server2:partition-Y

   vos remove server2 partition-Y volname.readonly

All of these update the VLDB.

> That seems like a waste of a command.  It would only be used in very
> rare situations that are otherwise correctable (just vos release and
> then vos remove.)

Yes, it is in fact a very rarely used command.  That
doesn't make it a waste though.  It serves a very specific
purpose for admins.

 > And why can't vos remove, vos zap or vos delentry be
 > used to remove a non-released replica?

vos remove: Can't be used because it will error out before
             it gets to the point where it's going to clean
             up the VLDB of the entry (what you are actually
             trying to do).

vos zap: Doesn't even apply here.  There's nothing on disk
          to ZAP if you have not released the replica in
          question.

vos delentry: How do you plan to specify the single RO to
               be removed when more than 1 exists?

In fact, you should be using 'vos delentry' and 'vos zap'
VERY rarely as well.

Used properly, vos addsite, vos release, and vos remove do
everything you will want 95% of the time... and they do the
right thing with the VLDB.  Instead, you are using "emergency"
commands on a regular basis which subvert either the disk
image or the VLDB consistency.  You're going to get yourself
in a real mess of a VLDB in time this way.