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

[Kim Kimball]

'vos delentry' is particularly dangerous -- it removes the entire VLDB 
entry and none of the data.

I had an admin (who I, embarrasingly enough, trained) who thought 'vos 
delentry' was the command to use when deleting a volume.

He learned a lot about 'vos syncvldb' and 'vos syncserv' (to repair the 
VLDB.)

Some of these commands could be improved by issuing a warning -- my pet 
peeve is "bos salvage <fileserver> [<partition>]"

The first message is "shutting down fs" and it does.

I don't forget very often any more.  It used to take quite a while to 
salvage 500 GB, and still irks my users/management/flight projects.

Kim

Jeff Blaine wrote:
>>> '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.
>
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info
>
>