<div dir="ltr"><span style="font-family:arial,sans-serif;font-size:13px">David,</span><div style="font-family:arial,sans-serif;font-size:13px"><a href="http://review.gluster.org/7501" target="_blank">http://review.gluster.org/7501</a> 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.)</div>
<div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">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.<br>
</div><div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">There are benefits and problems with both approaches.</div><div style="font-family:arial,sans-serif;font-size:13px">
HTH</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, May 19, 2014 at 11:57 AM, David F. Robinson <span dir="ltr"><<a href="mailto:david.robinson@corvidtec.com" target="_blank">david.robinson@corvidtec.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div>Avati, </div>
<div> </div>
<div>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?</div>
<div>It wasn't clear if the fixes were to take you up to the 93-group limit or beyond it... </div><span class="HOEnZb"><font color="#888888">
<div> </div>
<div>David</div></font></span><div><div class="h5">
<div> </div>
<div> </div>
<div>------ Original Message ------</div>
<div>From: "Anand Avati" <<a href="mailto:avati@gluster.org" target="_blank">avati@gluster.org</a>></div>
<div>To: "Niels de Vos" <<a href="mailto:ndevos@redhat.com" target="_blank">ndevos@redhat.com</a>></div>
<div>Cc: "gluster-users" <<a href="mailto:gluster-users@gluster.org" target="_blank">gluster-users@gluster.org</a>></div>
<div>Sent: 5/19/2014 2:50:54 PM</div>
<div>Subject: Re: [Gluster-users] 32 group limit</div>
<div> </div>
<div>
<blockquote cite="http://CAFboF2z1Q5+DB2e4dSgYeBXESxAH0GCqeJ-2qS0eAw=5+=bwoA@mail.gmail.com" type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">On Mon, May 19, 2014 at 8:39 AM, Niels de Vos <span dir="ltr"><<a href="mailto:ndevos@redhat.com" target="_blank">ndevos@redhat.com</a>></span> wrote:
<blockquote class="gmail_quote" style="PADDING-LEFT:1ex;MARGIN:0px 0px 0px 0.8ex;BORDER-LEFT:#ccc 1px solid">The 32 limit you are hitting is caused by FUSE. The Linux kernel module<br>provides the groups of the process that accesses the FUSE-mountpoint<br>
through /proc/$PID/status (line starting with 'Groups:'). The kernel<br>does not pass more groups than 32, this limit is hardcoded in the FUSE<br>kernel module.<br></blockquote>
<div><br></div>
<div>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)</div>
<div><br></div>
<div>Avati</div></div></div></div></blockquote></div></div></div></div></blockquote></div><br></div>