[OpenAFS] Unable to 'move' volume....volume ID too large / cloned
volume not findable?
Todd DeSantis
atd@us.ibm.com
Sun, 22 Mar 2009 16:46:48 -0400
--0__=08BBFF12DFE2B8768f9e8a93df938690918c08BBFF12DFE2B876
Content-type: text/plain; charset=US-ASCII
Hi Rainer - Hi Hartmut ::
>
> Yes, of course, but what error changed the MaxVolumeId in the vleserver
> is still completely unclear. BTW also we had a giant jump in the volume
> ids some years ago, but fortunately it was not big enough to reach the
> sign bit.
>
The MaxVolumeId can be changed several ways, via a "vos restore" and I
believe a "vos syncvldb or syncserv".
Most likely, the initial jump was via the "vos restore" command.
[src] vos restore -h
Usage: vos restore -server <machine name> -partition <partition name> -name
<nam
e of volume to be restored> [-file <dump file>] [-id <volume ID>]
[-overwrite <a
bort | full | incremental>] [-cell <cell name>] [-noauth] [-localauth]
[-verbose
] [-timeout <timeout in seconds >] [-help]
If you use the [-id <volume ID>] and have a typo in the volume ID, the
volumeID for the volume will be out of normal sequence and this will set
the MaxVolumeID to this large number.
Also, I believe that a "vos syncvldb or syncserv" will check the volumeIDs
it is playing with and will check it against the MaxVolumeID and raise
MaxVolumeID if necessary.
I think when we saw this happen to an AFS cell, we gave the customer a
tool to reset the MaxVolumeID to a more manageable number and they
restored the volumes and gave them lower IDs.
Thanks
Todd DeSantis
--0__=08BBFF12DFE2B8768f9e8a93df938690918c08BBFF12DFE2B876
Content-type: text/html; charset=US-ASCII
Content-Disposition: inline
<html><body>
<p>Hi Rainer - Hi Hartmut ::<br>
<br>
<tt>> <br>
> Yes, of course, but what error changed the MaxVolumeId in the vleserver<br>
> is still completely unclear. BTW also we had a giant jump in the volume<br>
> ids some years ago, but fortunately it was not big enough to reach the<br>
> sign bit.<br>
> </tt><br>
<br>
The MaxVolumeId can be changed several ways, via a "vos restore" and I<br>
believe a "vos syncvldb or syncserv".<br>
<br>
Most likely, the initial jump was via the "vos restore" command.<br>
<br>
<font face="Courier New">[src] vos restore -h</font><br>
<font face="Courier New">Usage: vos restore -server <machine name> -partition <partition name> -name <nam</font><br>
<font face="Courier New">e of volume to be restored> [-file <dump file>] [-id <volume ID>] [-overwrite <a</font><br>
<font face="Courier New">bort | full | incremental>] [-cell <cell name>] [-noauth] [-localauth] [-verbose</font><br>
<font face="Courier New">] [-timeout <timeout in seconds >] [-help]</font><br>
<br>
If you use the <font face="Courier New">[-id <volume ID>]</font> and have a typo in the volume ID, the<br>
volumeID for the volume will be out of normal sequence and this will set<br>
the MaxVolumeID to this large number.<br>
<br>
Also, I believe that a "vos syncvldb or syncserv" will check the volumeIDs <br>
it is playing with and will check it against the MaxVolumeID and raise <br>
MaxVolumeID if necessary.<br>
<br>
I think when we saw this happen to an AFS cell, we gave the customer a<br>
tool to reset the MaxVolumeID to a more manageable number and they <br>
restored the volumes and gave them lower IDs.<br>
<br>
Thanks<br>
<br>
Todd DeSantis<br>
<br>
</body></html>
--0__=08BBFF12DFE2B8768f9e8a93df938690918c08BBFF12DFE2B876--