Re: [Gluster-devel] Persistent AFR changelog attributes

[Pranith Kumar Karampuri]

----- 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?

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
>