<div dir="ltr">Meanwhile, I have made a csync2 test setup and I must say, I'm positively surprised by its performance. It keeps a local meta database (in SQLlite) of file checksums. Deleting and adding files works fine. Automatic conflict resolution works also acceptably well (in my setup: younger files win). Synchronization check of 180K files takes 10 seconds. Which could be further optimized by inotify hooks (lsyncd) which requires only partial synchronization. <div>
<br></div><div style>Still, I'd prefer the beauty of an integrated Gluster setup. My dream scenario is that Gluster would cooperate well with the kernel FSCache so that all small I/O requests could be served from memory. At the moment - AFAIK - this only works for the NFS client and then again only for a subset of I/O functions (which is understandable from a consistency perspective). </div>
<div style><br></div><div style>Thanks!</div><div style>//Willem</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Apr 24, 2013 at 2:18 PM, Marcus Bointon <span dir="ltr"><<a href="mailto:marcus@synchromedia.co.uk" target="_blank">marcus@synchromedia.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 class="im">On 24 Apr 2013, at 14:00, "Willem" <<a href="mailto:gwillem@gmail.com">gwillem@gmail.com</a>> wrote:<br>
<br>
>> I'm testing GlusterFS viability for use with a typical PHP webapp (ie. lots<br>
>> of small files). I don't care so much for the C in the CAP theorem, as I<br>
>> have very few writes. I could live with a write propagation delay of 5<br>
>> minutes (or dirty caches for up to 5 minutes).<br>
<br>
</div>We know that gluster's small-file performance isn't good, and since you can live with such long write propagation, reciprocal rsync could be a better and simpler solution. That way you'd get much faster local performance. The only issue really is that deletes aren't possible to propagate correctly with 2-way rsync (because a delete at one end is indistinguishable from an add at the other), but you may be able to live with it. csync2 aims to solve the delete issue with a transaction database, but I could never make it work.<br>
<br>
To get a consistent 0.2ms off anything you're going to need to be on SSDs - you can't fit everything in your cache.<br>
<span class="HOEnZb"><font color="#888888"><br>
Marcus<br>
--<br>
Marcus Bointon<br>
Synchromedia Limited: Creators of <a href="http://www.smartmessages.net/" target="_blank">http://www.smartmessages.net/</a><br>
UK info@hand CRM solutions<br>
<a href="mailto:marcus@synchromedia.co.uk">marcus@synchromedia.co.uk</a> | <a href="http://www.synchromedia.co.uk/" target="_blank">http://www.synchromedia.co.uk/</a><br>
</font></span><div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
Gluster-users mailing list<br>
<a href="mailto:Gluster-users@gluster.org">Gluster-users@gluster.org</a><br>
<a href="http://supercolony.gluster.org/mailman/listinfo/gluster-users" target="_blank">http://supercolony.gluster.org/mailman/listinfo/gluster-users</a><br>
</div></div></blockquote></div><br></div>