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

[giovanni bracco]

On Wednesday 27 October 2004 19:57, Jeffrey Hutzelman wrote:
> On Wednesday, October 27, 2004 09:26:49 +0200 giovanni bracco
>
....
>> 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.
>

we haven't not understood that; it happened quite long ago, so it means we 
have a substantial numer of volumes with "anomalous" ID number.

> > 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).

Yes, I have looked into that.
I have seen that the relevant value is the value MaxVolumeId which can be 
retrieved giving on the dbserver the command: 

vldb_check -vheader /usr/afs/db/vldb.DB0

I have also understood that the exact meaning of MaxVolumeId is  "the volume 
ID for the next volume to be created".

I have also located the position in the vldb.DB0 file where the value  
MaxVolumeId is stored and I have prepared a script to change it by using xxd 
and sed utility programs. It works nicely. I have tried it on a test cell and 
I am confident to be able to apply it on our production cell.

On the test cell have selected the machine which is the sync site and I have 
run on that a script which does the following:
1) stop the vlserver
2) apply the patch on vldb.DB0
3) restart the vlserver
All that takes just a few seconds, so soon after the restart the same dbserver 
is again the sync site for vldb.
At that  point when a new volume is created it is created with the new "good" 
id and  the value of MaxVolumeId is updated on all the other dbservers.
I have also noticed, it may be obvious of course, that just changing the 
MaxVolumeId in the vldb.DB0 does not triggers the update on the other 
dbservers. The update happens only when a new volume is created.

Of course I can also stop all the vlservers, patch all the vldb.DB0, and 
restart them but I don't think is really necessary.

>
> > 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).

I will make tests on all that: thank you for pointing out that kind of 
problems.

>
> 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...).
>

The option (2) seems more attractive to me and I think it can be a very 
usefull utility - it is exactely what I was looking for - so if you can find 
some time I am very interested in having that!

Ciao

Giovanni

-- 
Giovanni Bracco
ENEA INFO 
(Servizio Informatica e Reti)
Via E. Fermi 45
I-00044 Frascati (Roma) Italy
phone 00-39-06-9400-5597
FAX   00-39-06-9400-5735
E-mail  bracco@frascati.enea.it
WWW http://fusfis.frascati.enea.it/~bracco