[Gluster-users] Gluster-users Digest, Vol 51, Issue 46

[John Mark Walker]

----- Original Message -----

> Hi Ben,

> Thanks for the expert advice.

> On Fri, Aug 3, 2012 at 2:35 PM, Ben England < bengland at redhat.com >
> wrote:

> > 4. Re: kernel parameters for improving gluster writes on millions
> > of
> > small writes (long) (Harry Mangalam)
> 

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

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

-JM 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-users/attachments/20120806/63c841bc/attachment.html>