<html><head><style type='text/css'>p { margin: 0; }</style></head><body><div style='font-family: times new roman,new york,times,serif; font-size: 12pt; color: #000000'><br><br><hr id="zwchr"><blockquote style="border-left:2px solid rgb(16, 16, 255);margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><font><font face="verdana,sans-serif">Hi Ben,</font></font><div><font><font face="verdana,sans-serif"><br></font></font></div><div><font><font face="verdana,sans-serif">Thanks for the expert advice.<br></font></font><br><div class="gmail_quote">
On Fri, Aug 3, 2012 at 2:35 PM, Ben England <span dir="ltr"><<a href="mailto:bengland@redhat.com" target="_blank">bengland@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">4. Re: kernel parameters for improving gluster writes on millions of small writes (long) (Harry Mangalam)<br>
<br>
Harry, You are correct, Glusterfs throughput with small write transfer sizes is a client-side problem, here are workarounds that at least some applications could use.<br></blockquote><div><br></div><div id="DWT1302">Not to be impertinent nor snarky, but why is the gluster client written in this way and is that a high priority for fixing? It seems that caching/buffering is one of the great central truths of computer science in general. Is there a countering argument for not doing this?</div></div></div></blockquote><br>As a general point, you'll find that glusterfs always (almost always?) errs on the side of data consistency, even if it adversely affects performance. An NFS client can cache because it doesn't have to worry about HA - which has to be implemented with other tools. With recent changes in GlusterFS code, including further development of server-side code, it should be possible to create some type of client-side caching in the near future. There are also developments in fuse to think about, but mostly, it has to do with glusterfs' new server code. Previously, all the intelligence was in the client, so data consistency on the client was absolutely essential. Now, with "smarter" server-side translators, eg. self-heal and rebalancing, this is shifting. 3.3 was the first release with the shift in that direction, and more is coming. I know this doesn't help you *now*, but I wanted to give you an idea of why it is this way, and how it's changing going forward.<br><br>-JM<br><br><br></div></body></html>