<br><br><div class="gmail_quote">On Thu, May 10, 2012 at 1:18 AM, lejeczek <span dir="ltr"><<a href="mailto:peljasz@yahoo.co.uk" target="_blank">peljasz@yahoo.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<font size="-1"><font face="serif">glusterfs is a distributed file
system, fair enough, easy to maintain and very friendly to the
user<br>
still, comparing it against a raw (local) file system, like I do
via local mount point back ended with a single brick volume
would be a valid route to see what glusterfs does when most of
the variables are out of the equation.<br>
I mean a basic logic one would follow is, unless a volume is a
smartly distributed it would slow down even more (with some
formula) as soon as other media get involved<br>
thus I believe for simpler scenarios glusterfs won't do, for
instance one would like to run a live replica of a storage,<br>
a glusterfs two bricks replicated vol VS even only bidirectional
lsyncd<br>
lsyncd wins by miles, even for very deep data trees with lots of
files<br>
<br>
all may appreciate great bonus of clear and easy maintenance
gluster offers (yet still no AFR-like setups with command utils
possible) which is important for more complex configurations,
for simpler ones this bonus does not outweigh poor performance
gluster suffers from, well, in my opinion.<br>
<br></font></font></div></blockquote><div><br>What you end up actually comparing when you compare a local disk access with a loopback gluster on the same machine is the costant, high, per-syscall latency overhead of FUSE. Of course the comparison is going to be obscured badly. But this constant high latency becomes less of a problem the moment both the "participants" get a network round trip included in their operation.<br>
<br>When you are comparing gluster v/s lsyncd you are essentially comparing synchronous v/s asynchronous replication. They are very different techniques with very different applicability/expectations based on your use case.<br>
<br>Avati<br><br></div></div>