[Gluster-devel] Persistent AFR changelog attributes

Pranith Kumar Karampuri pkarampu at redhat.com
Wed Feb 12 06:45:13 UTC 2014



----- Original Message -----
> From: "Pranith Kumar Karampuri" <pkarampu at redhat.com>
> To: "Anand Avati" <avati at gluster.org>
> Cc: "Ravishankar N" <ravishankar at redhat.com>, "Gluster Devel" <gluster-devel at nongnu.org>
> Sent: Wednesday, February 12, 2014 11:44:08 AM
> Subject: Re: [Gluster-devel] Persistent AFR changelog attributes
> 
> 
> 
> ----- Original Message -----
> > From: "Pranith Kumar Karampuri" <pkarampu at redhat.com>
> > To: "Anand Avati" <avati at gluster.org>
> > Cc: "Ravishankar N" <ravishankar at redhat.com>, "Gluster Devel"
> > <gluster-devel at nongnu.org>
> > Sent: Wednesday, February 12, 2014 11:16:57 AM
> > Subject: Re: [Gluster-devel] Persistent AFR changelog attributes
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Anand Avati" <avati at gluster.org>
> > > To: "Ravishankar N" <ravishankar at redhat.com>
> > > Cc: "Gluster Devel" <gluster-devel at nongnu.org>
> > > 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?

After speaking to avati, he said KP knows more about this design. CC kp for inputs.

Pranith
> 
> > 
> > Pranith
> > 
> > > 
> > > Thanks,
> > > Avati
> > > 
> > > 
> > > On Tue, Feb 11, 2014 at 8:33 PM, Ravishankar N < ravishankar at redhat.com >
> > > 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
> > > Gluster-devel at nongnu.org
> > > https://lists.nongnu.org/ mailman/listinfo/gluster-devel
> > > 
> > > 
> > > _______________________________________________
> > > Gluster-devel mailing list
> > > Gluster-devel at nongnu.org
> > > https://lists.nongnu.org/mailman/listinfo/gluster-devel
> > > 
> > 
> 




More information about the Gluster-devel mailing list