[OpenAFS-devel] long volume names (was IPV6)

[Jeffrey Hutzelman]

On Wednesday, September 10, 2003 10:25:09 -0400 Derrick J Brashear 
<shadow@dementia.org> wrote:

> On Wed, 10 Sep 2003, Derrick J Brashear wrote:
>
>> Cheating would be possible if you didn't need to support .readonly, but
>> you do. (You still wouldn't have enough for an md5 hash).
>>
>> Cheating would be possible if you made the fileserver talk to the
>> VLserver, but you don't want to give it another communication path to bog
>> it down. Worse, the thing it could do (hand back mount points by
>> volumeid) would then require breaking callbacks on volumes with those
>> mountpoints if the mountpoint for a volume whose volume id changed was
>> in the volume... and you'd haave to keep track. It's doable but ugly if
>> you ignore the "don't want fileserver to need to call VLserver".
>>
>> So basically instead you want a one way hash which isn't likely to
>> ccollide, aand whicch can use the (22? i forget) characters you can fit
>> if you leave space for .readonly. I'm not sure how likely this is. I'm
>> also not sure what restrictions there are on character set for a volume
>> name, either.
>>
>> It's an idea, though.
>
> Duh.
>
> Make the vlserver allocate uuids tied to a volume name. Make the new
> volume header also support it, e.g. keep it as meta-info with the volume
> on the server also. Use that as your short name. It can simply be a 0
> padded counted index and you should still probably be fine.
>
> Then it just requires persistent storage in the vlserver such that a
> deleted volume keeps a name->uuid tie to be reused later if the name is
> recreated.


No, a UUID won't work; it has to be a computable hash.  The reason is that 
the fileserver doing name translation is the one that has the mount point, 
which may not be the same place as the mounted volume.  So if it's not 
computable, then the fileserver still has to call the vlserver.

Further, an MD5 hash fits just fine, if you encode it as base64 instead of 
hex.  An MD5 hash is 128 bits long; in base64, it will encode as a 
24-character string, and the last 2 characters will always be '=' (no other 
characters will be '=').  So you can drop the two trailing '=', leaving a 
22-character string which fits exactly into the volume name length limit. 
Further, these strings will not conflict with any "real" volume name which 
contains a '.', '-' or '_', since these are not in the base64 symbol set. 
root.afs and root.cell are examples of such names.

To further reduce the possibility of conflicts, one could note that the 
last character of the 22-character string carries only 2 bits of data, and 
in a standard encoding will always be one of 'A', 'Q', 'g', or 'w'.  These 
could be replaced with less likely characters, such as '@', '#', '$', and 
'%' or something.