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

Venky Shankar vshankar at redhat.com
Thu Oct 29 06:48:40 UTC 2015


On Thu, Oct 29, 2015 at 11:36 AM, Pranith Kumar Karampuri
<pkarampu at redhat.com> 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

Do you mean abstracting it out during volume creation? At a high level
this could be in the form of client or server
side replication. Not that AFR cannot be used on the server side
(you'd know better than me), but, if at all this level
of abstraction is used, we'd need to default to what fits best in what
use case (as you already mentioned below)
but still retaining the flexibility to override it.

> 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). Wanted to seek your inputs.
>
> Pranith
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel


More information about the Gluster-devel mailing list