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 < [email protected]> 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" <[email protected]> > To: "Niels de Vos" <[email protected]> > Cc: "gluster-users" <[email protected]> > 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 <[email protected]> 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 > >
_______________________________________________ Gluster-users mailing list [email protected] http://supercolony.gluster.org/mailman/listinfo/gluster-users
