Hi all, TL;DR: I'd appreciate it if someone can review http://review.gluster.org/7501
There is a well known limit for the number of groups (16) that NFS, or more specifically the RPC/AUTH_SYS header can transfer from client to server. Originally, Gluster suffered the same restriction, but by inventing it's own RPC/AUTH_GLUSTERFS_V2 header, this limit was overcome. Unfortunately, it seems that there is a protocol specification that limits the size of the RPC/AUTH header to 400 bytes [1]. The maximum number of groups that RPC/AUTH_GLUSTERFS_V2 can carry is limited to 93 (depending on the size of other attributes in the header) [2]. NFS servers have solved this by providing an option to resolve the groups on the NFS-server (using nss, ldap, nis, ..) and disregarding the groups from RPC/AUTH_SYS that the nfs-client sends. * The Gluster/NFS server offers this as a volume option: nfs.server-aux-gids * The Linux kernel NFS server offers --manage-gids for rpc.mountd. I'm proposing a similar option for the GlusterFS protocol. Internally Gluster can use up to 65535 groups, the limitation is completely contained in the RPC/AUTH_GLUSTERFS_V2 header. A new volume option called 'server.manage-gids' has been implemented and tested. This option causes the glusterfs-client to not send any auxiliary groups, and the brick processes will resolve the groups of the user themselves. This obviously, just like the NFS solution, requires that all storage servers can resolve the groups of any users (ldap, nis, ...). More reviews for http://review.gluster.org/7501 are more than welcome. A little of background and previous related bug fix can be found in [2]. Many thanks, Niels [1] http://tools.ietf.org/html/rfc5531#section-8.2 see opaque_auth [2] http://review.gluster.org/7202 _______________________________________________ Gluster-devel mailing list Gluster-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/gluster-devel