----- Original Message ----- > From: "Pranith Kumar Karampuri" <pkara...@redhat.com> > To: "Anand Avati" <av...@gluster.org> > Cc: "Ravishankar N" <ravishan...@redhat.com>, "Gluster Devel" > <gluster-devel@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" <pkara...@redhat.com> > > To: "Anand Avati" <av...@gluster.org> > > Cc: "Ravishankar N" <ravishan...@redhat.com>, "Gluster Devel" > > <gluster-devel@nongnu.org> > > Sent: Wednesday, February 12, 2014 11:16:57 AM > > Subject: Re: [Gluster-devel] Persistent AFR changelog attributes > > > > > > > > ----- Original Message ----- > > > From: "Anand Avati" <av...@gluster.org> > > > To: "Ravishankar N" <ravishan...@redhat.com> > > > Cc: "Gluster Devel" <gluster-devel@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 < ravishan...@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@nongnu.org > > > https://lists.nongnu.org/ mailman/listinfo/gluster-devel > > > > > > > > > _______________________________________________ > > > Gluster-devel mailing list > > > Gluster-devel@nongnu.org > > > https://lists.nongnu.org/mailman/listinfo/gluster-devel > > > > > > _______________________________________________ Gluster-devel mailing list Gluster-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/gluster-devel