Re: [Gluster-devel] Persistent AFR changelog attributes

[Pranith Kumar Karampuri]

----- Original Message -----
> From: "Pranith Kumar Karampuri" <address@hidden>
> To: "Anand Avati" <address@hidden>
> Cc: "Ravishankar N" <address@hidden>, "Gluster Devel" <address@hidden>
> Sent: Wednesday, February 12, 2014 11:16:57 AM
> Subject: Re: [Gluster-devel] Persistent AFR changelog attributes
> 
> 
> 
> ----- Original Message -----
> > From: "Anand Avati" <address@hidden>
> > To: "Ravishankar N" <address@hidden>
> > Cc: "Gluster Devel" <address@hidden>
> > Sent: Wednesday, February 12, 2014 10:30:29 AM
> > Subject: Re: [Gluster-devel] Persistent AFR changelog attributes
> > 
> > Ravi,
> > We had earlier discussed a solution for this (sometime last year) by making
> > volgen remember xlator names and not reassign them. Copying KP with who I
> > had discussed this to quite a level of detail. Have you guys spoken about
> > this? IIRC the solution KP and I discussed was more generic and could also
> > support retaining user made changes/customizations to the volfiles.
> 
> How will new machines that are joining the cluster will know about this
> modified graph? One way to achieve it is to send the skeleton structure of
> the graph to other machines. I wonder how this will address snapshot
> volumes' graph. May be even in the case of snapshot volumes, the skeleton
> has to be copied over to snapshot volume. So instead of storing just the
> client xlator names, the generic solution will have to store the entire
> skeleton and should keep it in sync at the time of probe, snapshot. Is that
> the rough algo you guys discussed? Did I miss anything?

If this indeed is the approach, I don't see an easy way out for generating 
brick volfiles according to versions. Brick processes don't have graph 
switching capability yet. Because of this, new versions may need to generate 
new xlators (Ex: barrier xlator that is going to come in for 3.6) in new 
versions but not for old versions. In essence the skeleton that is stored for 
one version could be incompatible for other versions. Then we will have to 
start having some sort of conversion mechanisms of the skeletons from one 
version to other. It seems a bit complicated :-(. Any suggestions?

> 
> Pranith
> 
> > 
> > Thanks,
> > Avati
> > 
> > 
> > On Tue, Feb 11, 2014 at 8:33 PM, Ravishankar N < address@hidden >
> > wrote:
> > 
> > 
> > Hello,
> > 
> > As you might perhaps be aware, AFR translator currently uses the client
> > translator names as the name of it's changelog extended attributes.
> > 
> > i)This can be a problem when a remove-brick operation is performed when
> > there
> > are pending heals happening because remove-brick causes a graph change
> > wherein the client translator names become different.
> > 
> > ii) Also, for gluster snapshot volumes to work correctly, there needs to be
> > a
> > persistent mapping of AFR changelog attributes to the bricks.
> > 
> > After some internal discussions, we have come up with a new naming
> > mechanism
> > that ensures backward compatibility. Details on the aforementioned problems
> > and the proposed solution are detailed in a feature page [1] for GlusterFS
> > 3.6.
> > Please feel free to go through it and give your comments/ critiques.
> > 
> > Thanks and regards,
> > Ravi
> > 
> > [1] https://www.gluster.org/ community/documentation/index.
> > php/Features/persistent-AFR- changelog-xattributes
> > 
> > ______________________________ _________________
> > Gluster-devel mailing list
> > address@hidden
> > https://lists.nongnu.org/ mailman/listinfo/gluster-devel
> > 
> > 
> > _______________________________________________
> > Gluster-devel mailing list
> > address@hidden
> > https://lists.nongnu.org/mailman/listinfo/gluster-devel
> > 
>