[Gluster-devel] pluggability of some aspects in afr/nsr/ec

[Shyam]

On 10/29/2015 02:06 AM, Pranith Kumar Karampuri wrote:
> hi,
>           I want to understand how are you guys planning to integrate
> NSR volumes to the existing CLIs. Here are some thoughts I had, wanted
> to know your thoughts:
> At the heart of both the replication/ec schemes we have
> 1) synchronization mechanisms
>         a) afr,ec does it using locks
>         b) nsr does it using leader election
> 2) Metadata to figure out the healing/reconciliation aspects
>         a) afr,ec does it using xattrs
>         b) nsr does it using journals
>
> I want to understand if there is a possibility of exposing these as
> different modules that we can mix and match, using options. If the users
> choose 1b, 2b it becomes nsr and 1a, 2a becomes afr/ec. In future if we
> come up with better metadata journals/stores it should be easy to plug
> them is what I'm thinking. The idea I have is based on the workload,
> users should be able to decide which pair of synchronization/metadata
> works best for them (Or we can also recommend based on our tests).

I wanted to add some more *insights* (or stir up the mess) based on the 
DHT2 MDS/DS split. With this case, we could (that may even change to a 
would) have NSR/AFR *only* on the MDS side of things and no EC there, 
and have any of EC/AFR/NSR on the DS side of things.

The theory being, EC provides data space efficiency and replicates 
meta-data anyway, so instead of having that on the MDS side of things, 
which does not have any data, we may want to stick to replication 
methods for availability reasons.

I am adding this here, although this is orthogonal to the current 
discussion, just to provide a perspective into our thought process.

> Wanted to seek your inputs.
>
> Pranith
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel