Re: [Gluster-devel] Split-brain present and future in afr

2014-05-23 Thread Pranith Kumar Karampuri
- Original Message - From: Jeff Darcy jda...@redhat.com To: Pranith Kumar Karampuri pkara...@redhat.com Cc: Gluster Devel gluster-devel@gluster.org Sent: Tuesday, May 20, 2014 10:08:12 PM Subject: Re: [Gluster-devel] Split-brain present and future in afr 1. Better protection

Re: [Gluster-devel] Split-brain present and future in afr

2014-05-23 Thread Jeff Darcy
Constantly filtering requests to use either N or N+1 bricks is going to be complicated and hard to debug. Every data-structure allocation or loop based on replica count will have to be examined, and many will have to be modified. That's a *lot* of places. This also overlaps

Re: [Gluster-devel] Split-brain present and future in afr

2014-05-23 Thread Justin Clift
On 23/05/2014, at 10:17 AM, Pranith Kumar Karampuri wrote: snip 2) That would need more bricks, more processes, more ports. Meh to more ports. We should be moving to a model (maybe in 4.x?) where we use less ports. Preferably just one or two in total if its feasible from a network layer.

[Gluster-devel] Split-brain present and future in afr

2014-05-20 Thread Pranith Kumar Karampuri
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

Re: [Gluster-devel] Split-brain present and future in afr

2014-05-20 Thread Jeff Darcy
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