From: Ray Lee <ray-lk@madrabbit.org>
To: linux-kernel@vger.kernel.org, "Bill Ryder" <bryder@wetafx.co.nz>
Subject: Re: [PATCH 2.6.18-rc1] Make group sorting optional in the 2.6.x kernels
Date: Tue, 11 Jul 2006 12:27:12 -0700 [thread overview]
Message-ID: <44B3FB90.6050106@madrabbit.org> (raw)
In-Reply-To: <2c0942db0607111120h686e70x44037730a1a4c92f@mail.gmail.com>
(Sorry for the duplicate, Bill -- lkml bounced my gmail account's message.)
In addition to Randy's fine comments...
On 7/10/06, Bill Ryder <bryder@wetafx.co.nz> wrote:
> Like many places Weta Digital (we did the VFX for Lord of the Rings,
> King Kong etc) uses supplemental group lists to allow users access to
> multiple directories and files (films mostly in our case) .
> Unfortunately NFSv2 and NFSv3 AUTH_UNIX flavour authentication is
> hardcoded to only support 16 supplemental groups. Since we currently
> have some users and processes which need to be in more than 16 groups
> we use setgroups to build a list of groups that a process requires
> when they access data on nfs exported filesystems.
>
> This worked fine for the 2.4.x kernels. 2.6.x is designed to handle
> thousands of groups for a single user. To support that the kernel was
> changed to sort the group list, then use a binary search to decide if
> a user was in the correct group. Unfortunately this BREAKS the use of
> setgroups(2) to put the 16 most important groups first.
>
> This patch provides the option of not sorting that list. The help
> describes the pitfalls of not sorting the groups (performance when
> there are a lot of groups).
It seems there's a third way to do this that would maintain setgroups(2)
compatibility and speed when you have a lot of groups.
Maintain the list of groups such that the first sixteen correspond to
what setgroups(2) requested, and keep the rest sorted. A search for
groups would then linearly check each of the first sixteen entries then,
if there's more, binary search the remainder from 16 to group_info->ngroups.
That'd allow this to be enabled everywhere (removing the CONFIG_
option), maintain backward compatibility, and still be fast in the face
of thousands of groups. The down side is slightly more complex code.
Well, and that you have to write it :-/.
On the other hand, as I haven't looked at the groups code, my suggestion
may be, y'know, nuts.
Ray
next prev parent reply other threads:[~2006-07-11 19:27 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-07-11 4:26 [PATCH 2.6.18-rc1] Make group sorting optional in the 2.6.x kernels Bill Ryder
2006-07-11 5:29 ` Randy.Dunlap
[not found] ` <2c0942db0607111120h686e70x44037730a1a4c92f@mail.gmail.com>
2006-07-11 19:27 ` Ray Lee [this message]
[not found] ` <2c0942db0607111109n14353c50wdaf144214d572ffe@mail.gmail.com>
2006-07-11 20:22 ` Bill Ryder
2006-07-19 8:02 ` Frank van Maarseveen
2006-07-19 20:17 ` Bill Ryder
2006-07-20 9:35 ` Frank van Maarseveen
2006-07-20 20:40 ` Bill Ryder
2006-07-20 22:11 ` Frank van Maarseveen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=44B3FB90.6050106@madrabbit.org \
--to=ray-lk@madrabbit.org \
--cc=bryder@wetafx.co.nz \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox