[OpenAFS] How to stop the access to an AFS volume ?

[Jeffrey Hutzelman]

On Wednesday, October 27, 2004 09:26:49 +0200 giovanni bracco 
<bracco@frascati.enea.it> wrote:

> vos offline <server_name> <partition_letter> <volume name> <seconds to
> remain  offline>
>
> During the offline period the volume is marked by "busy" status
> e.g.:
>
> [olavo@bracco bologna]$ vos examine user.bracco_bol
> **** Volume 2258391753 is busy ****
>
> so I can NOT make any action on the volume:
>
> vos dump -server f50.bologna.enea.it -partition c -id user.bracco_bol
> -file  /tmp/vol_user.bracco_bol
>
> Could not start transaction on the volume 2258391753 to be dumped
> VOLSER: volume is busy
> Error in vos dump command.
> VOLSER: volume is busy

Yeah; that's going to happen.  You will get the busy-volume volume 
behaviour during a dump even without vos offline, but from what you say 
below it sounds like you actually want the "old" volume to be permanently 
offline until you replace it with the new one.


> In my AFS cell many volumes have an anomalous Vol ID: it can be seen in
> the  previous example: ID=2258391753

Ow.  I didn't notice that until you pointed it out.
I'm not sure I want to know how you got such large volume ID's.


> Now I would like to go back to a normal situation, so that I can use
> OpenAFS  software on file server.
> To attain this I have to convert volumes with anomalous Vol ID into
> standard  volumes and I have seen that I can do that by a vos dump and
> vos restore  sequence.

You can, but you should be aware that anytime a volume ID is needed for a 
new volume and you didn't provide one (and there are cases where you 
_cannot_ provide one, such as with the temporary ID's used during volume 
moves), an ID is allocated by asking the vlserver for the "next available" 
volume ID.  This is managed using a counter kept in the VLDB, so if you 
want to stop having huge volume ID's, you will need some way to reset the 
counter.  I do not believe there is currently any interface for this, which 
means you'll need to either write some code, convince someone else to do 
so, or manually modify the database (rather perilous).



> I would like to be sure that any user is not able to make any
> modification to  a selected volume while the vos dump and vos restore
> sequence is in progress  and that is the reason to look for a "off-line"
> feature.
> Alas the vos offline command seems not to be what I was looking for.


I do not envy you the problem you have on your hands.  Changing volume ID's 
is not going to be transparent no matter what you do -- clients cache 
name-to-ID lookups, so once you "renumber" a volume any clients that care 
will have to do an 'fs checkv' in order to notice the change -- and I'm not 
positive even that will work (it should be easy to test).

However, I do think you can get the effect you want, in one of at least 
acouple of ways.  They're both going to involve building some stuff of your 
own...


(1) Build yourself a patched copy of vos in which 'vos dump' leaves the 
volume offline after dumping it.  This is a relatively simple change in 
src/volser/vsprocs.c:UV_DumpVolume().  Just above the error_exit: label, 
you want to insert a call to AFSVolSetFlags() to set the volume's flags so 
it stays offline after the transaction.  You can copy the relevant call 
from UV_SetVolume(); you want the third parameter to be VTOutOfService.

With this approach, the volume will go offline when you start the dump, and 
will stay that way after the dump is complete.  As with 'vos offline', the 
state is temporary, so if the fileserver restarts the volume will go online 
again.


(2) Build the vol-bless and vol-unbless utilities, which allow you to 
manipulate the persistent "Blessed" bit on a volume.  Unblessing a volume 
will take it out of service indefinitely.  You should still be able to dump 
and restore the volume without problems.  The state of the "blessed" bit is 
recorded in the volume dump, so the newly-restored volume may have to be 
manually blessed before it will be available.

The downside here is that vol-bless/vol-unbless must be run on the 
fileserver containing the volume whose blessed bit you want to manipulate. 
Also, while these utilities are fairly simple, the code is somewhat old and 
may not build cleanly.  If you want copies of these tools, let me know and 
I'll try to produce a version I can distribute (really, I should submit 
patches, but there are only so many hours in the day...).

-- Jeffrey T. Hutzelman (N3NHS) <jhutz+@cmu.edu>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA