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

[Derrick J Brashear]

On Wed, 10 Sep 2003, Leif Johansson wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Derrick J Brashear wrote:
> | On Wed, 10 Sep 2003, David Howells wrote:
>
> <snip>
>
> | behind them (multiple ROs support, IPv6, longer volume name length limit
> ~                                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> Yes please :-)

So, this is sick, and it requires making the fileserver do evil.

Volumes and any mount points on the servers get converted to "long" volume
names, whatever length they end up being. New clients set a bit in the
TellMeAboutYourself RPC saying they support these. Old clients get some
sort of hash of the volume name, and we pray the hashes don't collide.
Fileserver rewrites mount points on the fly to these clients to be "old"
length, e.g. the hash, and the old RPCs to the VLserver of course do the
same.

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.