[Gluster-users] Performance optimization tips Gluster 3.3? (small files / directory listings)

Pranith Kumar Karampuri pkarampu at redhat.com
Thu Jun 7 13:46:40 UTC 2012

hi Brian,
    'stat' command comes as fop (File-operation) 'lookup' to the gluster mount which triggers self-heal. So the behavior is still same.
I was referring to the fop 'stat' which will be performed only on one of the bricks.
Unfortunately most of the commands and fops have same name.
Following are some of the examples of read-fops:

----- Original Message -----
From: "Brian Candler" <B.Candler at pobox.com>
To: "Pranith Kumar Karampuri" <pkarampu at redhat.com>
Cc: "olav johansen" <luxis2012 at gmail.com>, gluster-users at gluster.org, "Fernando Frediani (Qube)" <fernando.frediani at qubenet.net>
Sent: Thursday, June 7, 2012 7:06:26 PM
Subject: Re: [Gluster-users] Performance optimization tips Gluster 3.3? (small	files / directory listings)

On Thu, Jun 07, 2012 at 08:34:56AM -0400, Pranith Kumar Karampuri wrote:
> Brian,
>   Small correction: 'sending queries to *both* servers to check they are in sync - even read accesses.' Read fops like stat/getxattr etc are sent to only one brick.

Is that new behaviour for 3.3? My understanding was that stat() was a
healing operation.

If this is no longer true, then I'd like to understand what happens after a
node has been down and comes up again.  I understand there's a self-healing
daemon in 3.3, but what if you try to access a file which has not yet been

I'm interested in understanding this, especially the split-brain scenarios
(better to understand them *before* you're stuck in a problem :-)

BTW I'm in the process of building a 2-node 3.3 test cluster right now.



More information about the Gluster-users mailing list