<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 2, 2017 at 12:30 AM, Shyam <span dir="ltr"><<a href="mailto:srangana@redhat.com" target="_blank">srangana@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 05/01/2017 02:55 PM, Pranith Kumar Karampuri wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<br>
<br>
On Tue, May 2, 2017 at 12:20 AM, Gandalf Corvotempesta<br>
<<a href="mailto:gandalf.corvotempesta@gmail.com" target="_blank">gandalf.corvotempesta@gmail.c<wbr>om</a><br></span><span class="">
<mailto:<a href="mailto:gandalf.corvotempesta@gmail.com" target="_blank">gandalf.corvotempesta@<wbr>gmail.com</a>>> wrote:<br>
<br>
2017-05-01 20:43 GMT+02:00 Shyam <<a href="mailto:srangana@redhat.com" target="_blank">srangana@redhat.com</a><br></span>
<mailto:<a href="mailto:srangana@redhat.com" target="_blank">srangana@redhat.com</a>>>:<span class=""><br>
> I do agree that for the duration a brick is replaced its replication count<br>
> is down by 1, is that your concern? In which case I do note that without (a)<br>
> above, availability is at risk during the operation. Which needs other<br>
> strategies/changes to ensure tolerance to errors/faults.<br>
<br>
Oh, yes, i've forgot this too.<br>
<br>
I don't know Ceph, but Lizard, when moving chunks across the cluster,<br>
does a copy, not a movement<br>
During the whole operation you'll end with some files/chunks<br>
replicated more than the requirement.<br>
<br>
<br>
Replace-brick as a command is implemented with the goal of replacing a<br>
disk that went bad. So the availability was already less. In 2013-2014 I<br>
proposed that we do it by adding brick to just the replica set and<br>
increase its replica-count just for that set once heal is complete we<br>
could remove this brick. But at the point I didn't see any benefit to<br>
that approach, because availability was already down by 1. But with all<br>
of this discussion it seems like a good time to revive this idea. I saw<br>
that Shyam suggested the same in the PR he mentioned before.<br>
</span></blockquote>
<br>
Ah! I did not know this, thanks. Yes, in essence this is what I suggest, but at that time (13-14) I guess we did not have EC, so in the current proposal I include EC and also on ways to deal with pure-distribute only environments, using the same/similar scheme.<span class=""><br></span></blockquote><div><br></div><div>Yeah this whole discussion came up because we wanted to deprecate pump xlator which was doing what we are discussing here on the brick side for both replicate and distribute(EC didn't exist at the time) but it had its problems. So Avati at the time suggested we use replace-brick for replica and remove-brick/add-brick for distribute and deprecate pump. I suggested we could instead increase replica count for just that brick(plain-distribute)/replica set alone. I just didn't have strong reason to push for it because I never thought of this usecase at the time. If I knew we would have had this feature in action ;-).<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
<br>
If you have a replica 3, during the movement, some file get replica 4<br>
In Gluster the same operation will bring you replica 2.<br>
<br>
IMHO, this isn't a viable/reliable solution<br>
<br>
Any change to change "replace-brick" to increase the replica count<br>
during the operation ?<br>
<br>
It can be done. We just need to find time to do this.<br>
</blockquote>
<br></span>
Agreed, to add to this point, and to reiterate. We are looking at "+1 scaling", this discussion helps in attempting to converge on a lot of why's for the same at least, if not necessarily the how's.<br>
<br>
So, Gandalf, it will be part of the roadmap, just when we maybe able to pick and deliver this is not clear yet (as Pranith puts it as well).<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br><span class="HOEnZb"><font color="#888888">
<br>
--<br>
Pranith<br>
</font></span></blockquote>
</blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Pranith<br></div></div>
</div></div>