[Gluster-users] Replicate performance (cluster/replicate, performance/io-cache)

[Alex Craven]

On Mon, Sep 14, 2009 at 10:41:51AM -0400, Mark Mielke uttered:
> On 09/14/2009 08:27 AM, Alex Craven wrote:
>> 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.

The dr sync is a slightly different approach -- I'd still hoped for
bidirectional replication in this case, just not necessarily
instantaneously. Still, this looks like something I'll need in future, so
thanks!

For now I think something like inotify+rsync will probably serve me
better... pity, I liked gluster in my brief encounter with it.



>> 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...

Yeah, this is exactly what I was hoping it could do. I'll see how feasible
it is to add something like this in...

At any rate, I still don't really see why this consistency check requires
four round trips? I wonder if this could be 'pipelined' somehow?

In terms of the snapshot possibly breaking half way though a read, is this
really any different from a local file being updated by another process
mid-read?



-- 
Alex Craven
krei at it.net.au