gluster-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gluster-devel] Persistent AFR changelog attributes


From: Pranith Kumar Karampuri
Subject: Re: [Gluster-devel] Persistent AFR changelog attributes
Date: Wed, 12 Feb 2014 01:52:10 -0500 (EST)

CCed now :-)

Pranith
----- Original Message -----
> From: "Pranith Kumar Karampuri" <address@hidden>
> To: "Anand Avati" <address@hidden>
> Cc: "Gluster Devel" <address@hidden>
> Sent: Wednesday, February 12, 2014 12:15:13 PM
> Subject: Re: [Gluster-devel] Persistent AFR changelog attributes
> 
> 
> 
> ----- 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:44:08 AM
> > Subject: Re: [Gluster-devel] Persistent AFR changelog attributes
> > 
> > 
> > 
> > ----- 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?
> 
> 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 < 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
> > > > 
> > > 
> > 
> 
> _______________________________________________
> Gluster-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/gluster-devel
> 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]