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.
_______________________________________________ OpenAFS-devel mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-devel
