[OpenAFS] Maximum # of users
Wed, 11 Apr 2007 02:21:50 -0400
On Monday, April 09, 2007 06:51:33 PM -0400 Marcus Watts <firstname.lastname@example.org>
> 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
> 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:email@example.com 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:firstname.lastname@example.org 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
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 :-)