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

[Derrick J Brashear]

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.