[Gluster-users] 32 group limit

[Anand Avati]

David,
http://review.gluster.org/7501 will "fix" the problem (in 3.5.x when it
gets backported), by providing a workaround solution where you (the admin)
will have to set up user accounts on the server side which are capable of
resolving the list of groupIDs for a user through getpwuid() call, and it
is the admin's responsibility to keep these credentials synchronized
(either using a centralized directory/ldap service or manually/scripting.)

In the last email I was referring to another approach where such an "extra
setup" is not necessary and the gluster native client and server can fetch
all the required groupIDs without any outside help.

There are benefits and problems with both approaches.
HTH


On Mon, May 19, 2014 at 11:57 AM, David F. Robinson <
david.robinson at corvidtec.com> wrote:

>  Avati,
>
> I am slightly confused.  Should we be able to utilize 93-groups with the
> current (3.5.0-2) release of gluster and fuse?  Or, are we stuck with
> 32-groups until the fixes are released in the next version?
> It wasn't clear if the fixes were to take you up to the 93-group limit or
> beyond it...
>
> David
>
>
> ------ Original Message ------
> From: "Anand Avati" <avati at gluster.org>
> To: "Niels de Vos" <ndevos at redhat.com>
> Cc: "gluster-users" <gluster-users at gluster.org>
> Sent: 5/19/2014 2:50:54 PM
> Subject: Re: [Gluster-users] 32 group limit
>
>
>  On Mon, May 19, 2014 at 8:39 AM, Niels de Vos <ndevos at redhat.com> wrote:
>>
>> The 32 limit you are hitting is caused by FUSE. The Linux kernel module
>> provides the groups of the process that accesses the FUSE-mountpoint
>> through /proc/$PID/status (line starting with 'Groups:'). The kernel
>> does not pass more groups than 32, this limit is hardcoded in the FUSE
>> kernel module.
>>
>
> Minor nit - 32 groupid limit is independent of FUSE. It is just the
> limited number of groupIDs the kernel exposes through proc. FUSE
> filesystems's only option is to use this sub-optimal interface to get group
> IDs. It is not unreasonable to actually implement a new reverse call in
> FUSE over /dev/fuse to resolve group-ids of a given request/process. Even
> then, the 400byte RPC limit of 93 would apply (we could at some point in
> the future move away from RPC)
>
> Avati
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-users/attachments/20140519/217b847f/attachment.html>