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

Kim Kimball dhk@ccre.com
Thu, 10 May 2007 13:18:53 -0600

'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 

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.


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