<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><br>
</p>
<br>
<div class="moz-cite-prefix">On 05/01/2017 11:55 AM, Pranith Kumar
Karampuri wrote:<br>
</div>
<blockquote
cite="mid:CAOgeEnZPVCMSE_n1gb9jqWdtqQUapZvUSpvnawNpeFhf8KwXBA@mail.gmail.com"
type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Tue, May 2, 2017 at 12:20 AM,
Gandalf Corvotempesta <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:gandalf.corvotempesta@gmail.com"
target="_blank">gandalf.corvotempesta@gmail.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="">2017-05-01 20:43 GMT+02:00 Shyam <<a
moz-do-not-send="true"
href="mailto:srangana@redhat.com">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>
<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>
</div>
</div>
</div>
</blockquote>
<br>
I've always been against the idea of being a replica down based on
that supposition. I've never had to replace-brick because a brick
failed. It's always been for reconfiguration reasons. Good
monitoring and analysis can predict drive failures in plenty of time
to replace a functioning brick.<br>
<br>
<blockquote
cite="mid:CAOgeEnZPVCMSE_n1gb9jqWdtqQUapZvUSpvnawNpeFhf8KwXBA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<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>
</blockquote>
</div>
It can be done. We just need to find time to do this.<br>
</div>
<div class="gmail_extra"><br clear="all">
<br>
-- <br>
<div class="gmail_signature" data-smartmail="gmail_signature">
<div dir="ltr">Pranith<br>
</div>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Gluster-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Gluster-users@gluster.org">Gluster-users@gluster.org</a>
<a class="moz-txt-link-freetext" href="http://lists.gluster.org/mailman/listinfo/gluster-users">http://lists.gluster.org/mailman/listinfo/gluster-users</a></pre>
</blockquote>
<br>
</body>
</html>