Date: Tue, 28 Sep 1999 12:47:24 +0100 (BST)
To: [EMAIL PROTECTED] (Dave Lorand)
cc: [EMAIL PROTECTED]
From: Paul Blackburn <[EMAIL PROTECTED]>
Subject: Re: AFS cell structure
...
Also, I believe large cells use indirection dirs for access to $HOMEs.
Eg: user's home volumes are mounted under:
/afs/@cell/users/u${NN}/${LOGNAME}
where ${NN} is the user's UID modulo 32, ${LOGNAME} is login name
Also, to simplyify access, symbolic links are used.
So, for example: LOGNAME=bender, UID=4719, therefore NN=15
/afs/@cell/home/b/e/bender -> /afs/@cell/users/u15/bender
The advantages of this are:
a) it is simple to find a home directory by simply cd'ing to
/afs/@cell/home/b/e/bender
* | *|
b) the "modulo 32" mountpoints evenly distribute $HOME volume
mounts below /afs/@cell/users/u${NN}/
c) ${HOME} mountpoint directories (/afs/@cell/users/u${NN}/)
and symbolic link directories (/afs/@cell/home/b/e/bender)
do not grow to too large. This is goodness since ls'ing
large directories takes time under /afs.
...
Note that using "UID modulo 32" as above may create more problems than
it solves. Consider a larger number if your cell will be of any size.
We use the first two characters of the user login as noted above and
then simply mount the user volumes at the place which the above example
would have you create the symbolic links. The result is an uneven
distribution of mount points based on users' choices of logins, but
we'd have to be using "UID modulo 64" before even our worst-off users
would see better performance on directory lookups with the UID concept
than on our current uneven hash into 676 buckets. Some have discussed
using a three letter hash instead of two if your cell will be huge.
Of course, if you use a letter-based hash at all, whether to get to a
mount point directly or a symbolic link for redirection, then make
sure that your user logins aren't all "user1", "user2", etc.
Pick a method that accounts for your wildest dreams in growth, because
once you pick you'll have a tough time changing to something else.
Steve
