[OpenAFS] Maximum # of users

[Jeffrey Hutzelman]

On Monday, April 09, 2007 06:51:33 PM -0400 Marcus Watts <mdw@umich.edu> 
wrote:

> Max user id is 851087 and max group id is -19786.

It's always fun to watch you demonstrate to someone that they're not really 
as big as they think they are.  It helps the rest of us keep a sense of 
perspective. :-)


> Older versions of ptserver had an option called "CROSS_CELL",
> which had some sort of split 16-bit assumption about viceIDs.
> We never ran with this at umich.edu, and the code seems to be gone
> in modern versions of openafs.

Actually, you're running that code now.  The ptserver had some notion of 
foreign users as far back as the end of 1988, but it wasn't fully developed 
then; in fact, that code wouldn't let anyone create an entry with an '@' in 
its name, ever, though you could apparently create entries with PRFOREIGN 
set and no '@' in the name, even if you were an ordinary user!

The modern form of cross-cell authentication first appeared in AFS 3.2, 
along with the CROSS_CELL macro which enabled it.  Starting in AFS 3.5, 
that functionality was turned on by default, and references to the 
CROSS_CELL macro went away.

Foreign users are identified by the presence of an '@' in their name, and 
can only be created if the corresponding system:authuser@cell.name group 
exists.  The group quota on that entry is used to control the number of 
users that can be created from that cell; when it runs out someone needs to 
add more in order to allow more users to be created.

ID's for foreign users are based on the ID of the corresponding 
system:authuser@cell.name group.  The low-order 16 bits of a foreign user 
ID are the same as those of the group; the high-order bits start at 1 and 
increment for each new user.  If you have two foreign-cell groups whose 
ID's are the same in the low-order 16 bits, then users from those cells 
will have ID's drawn from the same namespace.  In AFS 3.2, the allocation 
method was primitive; each foreign-cell group has a counter which records 
the next available ID for that cell; if that ID was not available, then no 
new users could be created in that cell until an admin created one with an 
explicit ID (drawn from the correct range).  Today, the counter is still 
used, but only as an optimization; the ptserver starts from there and 
searches for the next available value, similar to what is done for user and 
group ID's.

So, there is a limit of 2^15-1 foreign users per cell, and a nominal limit 
of 2^31-1 users in total.  However, before you reach 2^31-1 users, your 
PRDB will grow too large for Ubik to handle -- the DISK protocol can't 
handle file sizes or offsets larger than 2^31-1, and PTS entries are 192 
bytes, which means you'll max out at around 11 million entries (including 
the extension blocks used when a user or group has more than 10 
memberships).  Of course, that's assuming you don't start having problems 
with recovery first.



> Older unix systems had a 16-bit uid limit

Except Ultrix, which had a limit of exactly 32000, above which setuid() 
would fail :-)


-- Jeff