<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 1, 2017 at 2:55 PM, Pranith Kumar Karampuri <span dir="ltr"><<a href="mailto:pkarampu@redhat.com" target="_blank">pkarampu@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Tue, May 2, 2017 at 12:20 AM, Gandalf Corvotempesta <span dir="ltr"><<a href="mailto:gandalf.corvotempesta@gmail.com" target="_blank">gandalf.corvotempesta@gmail.<wbr>com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>2017-05-01 20:43 GMT+02:00 Shyam <<a href="mailto:srangana@redhat.com" target="_blank">srangana@redhat.com</a>>:<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>
</span>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></blockquote><div><br></div></span><div>Replace-brick as a command is implemented with the goal of replacing a disk that went bad. So the availability was already less. In 2013-2014 I proposed that we do it by adding brick to just the replica set and increase its replica-count just for that set once heal is complete we could remove this brick. But at the point I didn't see any benefit to that approach, because availability was already down by 1. But with all of this discussion it seems like a good time to revive this idea. I saw that Shyam suggested the same in the PR he mentioned before.<br></div><span class=""><div> </div></span></div></div></div></blockquote><div><br></div><div>The ability to increase and decrease the replication count within a replica set would be pretty cool. In addition to replace-brick, workloads that need elasticity to serve reads can benefit from more replicas to provide load balancing. Once the load is back to normal, we can cull the temporary brick.</div><div><br></div><div>We might also want to start thinking about spare bricks that can be brought into a volume based on some policy. For example, if the posix health checker determines that underlying storage stack has problems, we can bring a spare brick into the volume to replace the failing brick. More policies can be evolved for triggering the action of bringing in a spare brick to a volume.</div><div><br></div><div>-Vijay</div><div><br></div><div>-Vijay</div></div></div></div>