> Speaking from my experience, I really like the UM scheme. It's
> immediately obvious to anyone where someone else's home directory is,
> so they can go looking in /afs/ir/users/j/o/... I'd never guess what
> your UID is, and my shell on my workstation here is probably never going
> to do the right thing with "ls ~[EMAIL PROTECTED]". Why don't you just
> add a level: /afs/ir/users/[a-z]/[a-z]/[a-z][0-9]/$USER (ie,
> /afs/ir/users/j/o/h/john)
Well, in my mind, that scheme is a kluge, but for those without
a naming service (like Hesiod or someday perhaps DCE CDS) I
can see why it has some appeal.
> I'd like to explore a little bit why you think that more than 31 entries
> in a directory is a problem. Since that may not be of general interest
> to the list, why don't you send me email?
I wouldn't say more than 32 (or 31) entries is a problem.
But, by my estimation, it is optimal for us.
We have a target/limit of 32K (2^15) users.
Obviously, having 32K users in one directory is too big/too slow.
Ok, how about 2 levels, optimally divided that would be
181 directories of 181 entries. Not too horrible, a
directory listing will even just barely fit on the screen.
still, it's kind of slow. Hard to think of a good way
to divide by 181 though, probably have to use 256,128
or 128,256.
Ok, how about 3 levels, that's 32 dirs of 32 dirs of 32 entries.
fast, looks pretty good, plus it divides nicely.
Ok, how about 4 levels of 14 (or 16,16,16,8). I think we've
reached the point of diminishing returns now.
Now, the question is how to achieve an even balancing of users
among these directories. Dividing the UID seemed a natural
(esp. since we have no need for the actual path to be guessable).
Even with .../u/s/e/username we have 89 "mar"s, 69 "sch"s, etc.
(and since 3 is the minimum username length, going more than
3 levels seems really yucky).
John
