Re: [BK PATCH 1/4] fix NGROUPS hard limit (resend)

>>>>> "Jesse" == Jesse Pollard <[e-mail]> writes:

Jesse> On Tuesday 22 October 2002 12:37 pm, Tim Hockin wrote:
>> Alan Cox wrote:
>> > On Tue, 2002-10-22 at 18:26, Tim Hockin wrote:
>> >>Alan Cox wrote:
>> >>>Ok sanity check time. Why do you need qsort and bsearch for this kind of
>> >>>thing. Just how many groups do you plan to support ?
>> >>
>> >>Unlimited - we've tested with tens of thousands.
>> >
>> > Now how about the real world requirements ?
>> 
>> Those were real world requirements - we got the number 10,000 from our
>> product management, which (presumably) spoke with customers.  On the
>> hosting systems, it is really possible to have thousands of virtual sites.
>> 
>> Now, I don't much care if you want it to be a linear search, and I'll
>> revert it, if needed, but qsort() is already in in XFS specific code,
>> and bsearch is small.  It doesn't negatively impact any fast path, and
>> provides better behavior for the crazies that really want 10,000 groups.
>> 
>> Tim

Jesse> Does it actually work with NFS???? or any networked file
Jesse> system?  Most of them limit ngroups to 16 to 32, and cannot
Jesse> send any data if there is an overflow, since that overflow
Jesse> would replace all of the data you try to send/recieve...

Jesse> And I really doubt that anybody has 10000 unique groups (or
Jesse> even close to that) running under any system. The center I'm at
Jesse> has some of the largest UNIX systems ever made, and there are
Jesse> only about 600 unique groups over the entire center. The
Jesse> largest number of groups a user can be in is 32. And nobody
Jesse> even comes close.

  $ ypcat group | wc -l
  9527

  $ ypcat passwd | wc -l
  62076

Yes, we're insane :-)

OTOH, we use AFS and PTS groups, because Unix groups don't scale.  And
we would not use the ngroups mechanism in Linux even if it did,
because we need to inter-operate with Solaris.

Cheers, Hildo