<html><head></head><body>I kill (SIGTERM) the glusterfsd process for the specific brick. <br>
<br>
To restart that brick, "gluster volume start $vol force".<br><br><div class="gmail_quote">Michael Peek <peek@nimbios.org> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="k9mail">Hi guys,<br /><br />I have a cluster with replication (four machines, two drives in each)<br />for testing that I've been beating on. I've just simulated one type of<br />hardware failure by remounting a drive read-only.<br /><br />The manual covers many useful things: Adding/removing peers;<br />Starting/stopping, creating, expanding, shrinking, and deleting volumes;<br />etc. But it doesn't cover what you should do to replace a failed brick<br />to minimize frustration and chances of data loss.<br /><br />I can't unmount the brick because glusterfs still has open files on it.<br /><br />If I stop the glusterfs-server then that takes the other brick in the<br />machine out of commission too.<br /><br />I have the same problem if I reboot the machine -- I take the other<br />brick out of service.<br /><br />What's the correct way to deal with this? Is there a way to tell<br />gluster to take a brick out of commission for replacement without<br />interrupting
access to other bricks in the same machine?<br /><br />Thanks for your help,<br /><br />Michael Peek<br /><hr /><br />Gluster-users mailing list<br />Gluster-users@gluster.org<br /><a href="http://supercolony.gluster.org/mailman/listinfo/gluster-users">http://supercolony.gluster.org/mailman/listinfo/gluster-users</a><br /></pre></blockquote></div></body></html>