[Gluster-devel] Restricting add-brick when volume is stopped.

[Anuradha Talur]

----- Original Message -----
> From: "Kaushal M" <kshlmster at gmail.com>
> To: "Anuradha Talur" <atalur at redhat.com>
> Cc: "Gluster Devel" <gluster-devel at gluster.org>
> Sent: Tuesday, February 23, 2016 1:04:32 PM
> Subject: Re: [Gluster-devel] Restricting add-brick when volume is stopped.
> 
> On Tue, Feb 23, 2016 at 12:57 PM, Anuradha Talur <atalur at redhat.com> 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 at gluster.org
> > http://www.gluster.org/mailman/listinfo/gluster-devel
> 

-- 
Thanks,
Anuradha.