Hello (again), I write after making "adjustments" to my hardware (from a single Caviar green to a raid array of Caviar blacks). I would still love feedback about users with smaller systems for storing user home directories in my range of hardware, as to expectations/sizing, etc. (maybe in response to my mail from yesterday?) One concrete problem I'm trying to resolve at the moment is with file system permissions. In short, a user with gid=X and groups=Y,Z can work in folders that are owned by group X and permissions 770, but can not read/list the contents of a directory owned by group Y and permissions 770. The clients mount glusterfs directly. I double checked permissions on the gluster underlying brick's file systems and via the gluster mount; made sure there are no ACLs (via getfacl) -- not sure what to check else? After a bit of googling I found only a mail to this mailling list from December without answer (http://www.mail-archive.com/gluster-users at gluster.org/msg04478.html). In the end, I managed to find the bug report http://bugs.gluster.com/cgi-bin/bugzilla3/show_bug.cgi?id=2183, which (per the comments) is still open in 3.1.2 -- but maybe it can't even be fixed at all by the Gluster devs (if it's really FUSE that is the problem as I understood from the comments)? Two questions then: - Is it really a FUSE or a Gluster issue that the additional groups aren't read? - Thinking about switching to NFS on the clients, does the built-in NFS service create more or less work for a distributed replicated system (due to a shifting in the responsibility for the synchronization?) on the servers? I'd tend to think yes - but if yes, relatively speaking, how much? (at peaks during synchronization, I've seen upto overall 50% CPU use of a dual quad-core Xeon system). Input is welcome! Andrew
