On 07/10/2013 09:20 AM, Allan Latham wrote: > Where do I get a version that will solve my 'read local if we have the > file here' problem. I would say 3.4 is already far better than 3.3 not only in terms of features but stability/maintainability/etc. as well, even though it's technically not out of beta yet. You can get it here: http://download.gluster.org/pub/gluster/glusterfs/3.4/3.4.0beta4/ Selection of the local subvolume (if there is one) should happen automatically, and multiple users have reported that this is in fact the case. You can also use the read-subvolume-index option to gain explicit control over this decision at mount time (via the --xlator-option hook). > My use case is exactly two servers at a server farm with 100Mbit between > them. This 100Mbit is also shared with the outside internet. Hence the > need to minimise use of this very limited resource. That's very similar to the use case for the person who submitted the read-subvolume-index patch. > We are still in evaluation. Current 'best' is what we are familiar with > = unison and inotify. I don't like it because it's really only a hack. > However it works. If inotify misses a change due to race conditions > unison gets run every five minutes anyway. If you're running with that level of eventual consistency already, might geo-replication be a better fit for your needs? It's a separate feature from normal (synchronous) replication, described in section 8 of the 3.3 admin guide. http://www.gluster.org/wp-content/uploads/2012/05/Gluster_File_System-3.3.0-Administration_Guide-en-US.pdf Unfortunately, I can't find the 3.4 admin guide on the Gluster site (another pet peeve) or I'd provide a link to that.
