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

[Pranith Kumar Karampuri]

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:
        .access
        .stat
        .fstat
        .readlink
        .getxattr
        .fgetxattr
        .readv

Pranith.
----- 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.
http://gluster.org/community/documentation/index.php/Gluster_3.2:_Triggering_Self-Heal_on_Replicate

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

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.

Cheers,

Brian.