----- Original Message ----- > From: "Kaushal M" <kshlmster@xxxxxxxxx> > To: "Anuradha Talur" <atalur@xxxxxxxxxx> > Cc: "Gluster Devel" <gluster-devel@xxxxxxxxxxx> > Sent: Tuesday, February 23, 2016 1:04:32 PM > Subject: Re: Restricting add-brick when volume is stopped. > > On Tue, Feb 23, 2016 at 12:57 PM, Anuradha Talur <atalur@xxxxxxxxxx> wrote: > > Hi, > > > > AFR has a requirement that when replica count is changed while adding > > bricks to a volume, e.g., converting a replica 2 to replica 3, afr pending > > xattrs are marked to indicate this change. (To prevent potential > > data-loss) > > > > This is possible only when the volume is not stopped, which is a deviation > > from the present behaviour that allows add-brick even when the volume is > > stopped. I sent a patch : http://review.gluster.org/#/c/12451/ , if this > > change is included, only such add-brick operations that change replica > > count will be forbidden when the volume is stopped. I would like to know > > if there are any objections to this. > > This should be okay. But I'd like to know if other solutions are possible. > > (I'm not an AFR guy, so the below is based on my (mis)understanding of > how it works. Please correct me if I'm wrong.) > Is there no way for AFR to detect that the 3 brick is an empty brick? > When AFR requests the bricks for the pending xattrs, the new brick > wouldn't return any. AFR could then do a full heal to the new brick in > this case. > The new brick wouldn't have any pending xattrs if all the operations after adding the new brick succeeded on the other bricks. Meanwhile, if there were any operations succeeded on new brick and not on old brick, it may also result in reverse healing and loss of data. > I don't know how complex it would be to do such a check, but would > like to know if its possible. > > In anycase, I'm okay with the suggested volume online check in > GlusterD. I'll review the change and let you know if anything else is > needed. > > ~kaushal > > > > -- > > Thanks, > > Anuradha. > > _______________________________________________ > > Gluster-devel mailing list > > Gluster-devel@xxxxxxxxxxx > > http://www.gluster.org/mailman/listinfo/gluster-devel > -- Thanks, Anuradha. _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
