Hi Jeff OK - I've downloaded the source and I'm setting up to compile it for Debian Wheezy. I'll let you know how I get on. Maybe next week before I can run preliminary tests. Correct me if I'm wrong but geo-replication is master/slave? We could maybe go with this in some scenarios as updates should be controlled in any case so nominating a particular virtual server to be the master is no problem. This is the 'roll out the same html files on all the web servers' scenario. The web servers themselves mount this volume RO. We have other similar config file scenarios. Another use is really master/master and this is where we copy a backup to a directory under unison control knowing that it will be safely on two physical machines within a minute or two. Also use this as a lazy way to move files between physical servers. Later I want to also write log files to gluster so I know I've got them on the other server if one of them goes down. The nearer this is to 'sync mode' the better but I can't stop logging just because the peer machine is down or can't keep up. Unison can do this (I don't do it yet) because it's async. In short 'sync' replication is not an absolute must but we do use master/master quite a bit. I need to read up more on geo-replication. All the best Allan On 10/07/13 15:39, Jeff Darcy wrote: > 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. > > >
