hi,
Please resubmit the patches on top of http://review.gluster.com/#/c/7753 to
prevent frequent regression failures.
Pranith
- Original Message -
From: Vijaikumar M vmall...@redhat.com
To: Pranith Kumar Karampuri pkara...@redhat.com
Cc: Joseph Fernandes josfe...@redhat.com,
Ignore this, just testing mailing list archiving...
+ Justin
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://supercolony.gluster.org/mailman/listinfo/gluster-devel
hi,
Thanks to Vijay Bellur for helping with the re-write of the draft I sent him
:-).
Present:
Split-brains of files happen in afr today due to 2 primary reasons:
1. Split-brains due to network partition or network split-brains
2. Split-brains due to servers in a replicated group being
On Tue, May 20, 2014 at 01:30:24PM +0200, Niels de Vos wrote:
Hi all,
the last few days I've been looking at a problem [1] where a client
locks a file over a FUSE-mount, and a 2nd client tries to grab that lock
too. It is expected that the 2nd client gets blocked until the 1st
client
1. Better protection for split-brain over time.
2. Policy based split-brain resolution.
3. Provide better availability with client quorum and replica 2.
I would add the following:
(4) Quorum enforcement - any kind - on by default.
(5) Fix the problem of volumes losing quorum because
Hey,
Seems like even after this fix is merged, the regression tests are failing
for the same script. You can check the logs at
http://build.gluster.org:443/logs/glusterfs-logs-20140520%3a14%3a06%3a46.tgz
Relevant logs:
[2014-05-20 20:17:07.026045] : volume create patchy
build.gluster.org
Niels,
This is a good addition. While gluster clients do a reasonably good job at
detecting dead/hung servers with ping-timeout, the server side detection
has been rather weak. TCP_KEEPALIVE has helped to some extent, for cases
where an idling client (which holds a lock) goes dead. However if an