[Gluster-users] Gluster-users Digest, Vol 54, Issue 27

[John Mark Walker]

Israel - thank you for taking the time to write out more thoughtful responses. See below for my responses inline. 

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

> On 10/21/2012 02:18 PM, Israel Shirk wrote:
> > Haris, try the NFS mount. Gluster typically triggers healing
> > through
> > the client, so if you skip the client, nothing heals.
> Not true anymore. With 3.3 there's a self-heal daemon that will
> handle
> the heals. You do risk reading stale data if you don't read through
> the
> client though.

> It's not going to trigger this by writing to the brick itself, and
> doing 'ls -l' or stat is kind of a mess.
Actually, the self-heal daemon should work server-side now, and it shouldn't require an FS stat. That was one of the key features of 3.3. If you notice this not working properly, please file a bug, as that is not expected behavior. 

> > False. The client will read from the first-to-respond. Yes, if
> > Singapore

> >is responding faster than Virginia you might want to figure out why
> >Virginia is so overloaded that it's taking more than 200ms to
> >respond,
> >but really that shouldn't be the case.

> Totally agree. Should not be the case. Wish it was false. But when it
> suddenly sends EVERYTHING to Singapore from Virginia, not touching
> the servers in Virginia AT ALL, and you can mount them using NFS and
> it works great, I gotta point my finger at the client. You can
> disagree however much you want, but I'm talking from very
> frustrating experiences here.
GlusterFS algorithm is first-to-respond, as Joe suggested. I guess the question is, why are you seeing this behavior? That shouldn't be the case. I'd like to see some investigation of your particular setup to do some root cause analysis. 

A secondary question would be why you're not using geo-rep for that kind of setup, but I'd like to get an answer to the first question first. 

> > then when healing is needed it will take a bunch of time to do
> > that,
> > all the while it's blocking your application or web server, which
> > under heavy loads will cause your entire application to buckle.
> False. 3.3 uses granular locking which won't block your application.

> Blocking your application as in, taking so many file descriptors due
> to lag that the application runs out of file descriptors or
> connections and locks up.
This sounds like it stems from your replication issues, above. Solving the first problem should obviate this one. 

As always, please report any bugs you find to https://bugzilla.redhat.com/enter_bug.cgi?product=GlusterFS 

-JM 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-users/attachments/20121022/0f292edb/attachment.html>