On 09/14/2009 08:27 AM, Alex Craven wrote: > I've just started experimenting with glusterfs and am new to this list, so > apologies if this has all been covered before! (a quick browse through the > archives didn't reveal anything though) > > I'm attempting to use glusterfs to manage replication between a pair of > geographically separated test servers (communicating over an ssh tunnel). > I realise this isn't exactly an optimal configuration. However, I need > fast read performance but don't particularly care about write performance, > and it doesn't really matter if I'm reading 30-second-old data (my usage > is mainly for webserver replication, so the data won't be changing very > often anyway). > > Now, I've set up gluster as per the attached configurations. I believe all > the appropriate performance translators are configured, notably including > the io-cache. The read-subvolume is set to a posix storage on the local > machine. > > Still, in spite of the local read-subvolume and caching, successive read > operations on the same (tiny) file, well within the cache-timeout period > always take a minimum time equivalent to four round trips to complete. > The read subvolume only helps on read(). For every other request, such as open(), all of the replicas get involved. I think you are looking for the dr sync functionality they list on the roadmap for GlusterFS 2.2. > Can anyone explain why this is? I understand there may be one transaction > to validate the cache, but what else is going on here? Furthermore, is it > possible to defer/disable this re-validation (within a timeout) > altogether?luster.org/cgi-bin/mailman/listinfo/gluster-users > Not that I know of - and I think there would be many gotchas of doing such a thing - however, for certain use cases, it would be kind of cool if they could relax the restrictions and/or move operations such as consistency checks and self-heal to the background to be run asynchronously. For example, if I am doing open(..., O_RDONLY), read(), close(), then I may not care about the state of other volumes, as long as I see a consistent snapshot that doesn't break half-way through my read()s... Cheers, mark -- Mark Mielke<mark at mielke.cc>
