I have both read specifically that people with small files basically switched to NFS to solve small-file read issues and speed issues more generally. It seems to me (from my own testing as well), that 3.3 is still not working all that well with 'small files'. An image folder with about 20k images in it takes about 20+ seconds to do an 'ls' on, and about three seconds with NFS. It was enough of a speed difference on the front-end site to make me change my thinking and start working on getting keepalived working with gluster so that I can have a consistent NFS view. Justice London -----Original Message----- From: gluster-users-bounces at gluster.org [mailto:gluster-users-bounces at gluster.org] On Behalf Of David Coulson Sent: Friday, June 22, 2012 3:58 AM To: Fernando Frediani (Qube) Cc: 'gluster-users at gluster.org' Subject: Re: Switching clients to NFS On 6/22/12 6:18 AM, Fernando Frediani (Qube) wrote: > I have seen a few people recently saying they are using NFS instead of the Native Gluster client. I would imagine that the Gluster client would always be better and faster besides the automatic failover, but it makes me wonder what sort of problems their as experiencing with the Gluster client. > I ran FUSE mounts for a couple of months then switched to NFS. In general I saw an approx 2x improvement in read performance, and writes appeared to be a little quicker. Since my environment is 'mostly reads', as NFS utilizes the OS filesystem cache I saw a substantial drop in network traffic between Gluster nodes. I was also never able to get FUSE to mount volumes with an explicit SELinux context set. Not sure if it's a bug in FUSE on RHEL6, or just something broken with FUSE, but it just ignored the secontext= mount parameter. NFS works with this, so I was able to run SELinux in enforcing mode while using Gluster. David _______________________________________________ Gluster-users mailing list Gluster-users at gluster.org http://gluster.org/cgi-bin/mailman/listinfo/gluster-users
