<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 09/03/2013 10:45 AM, Anirban Ghoshal
      wrote:<br>
    </div>
    <blockquote
      cite="mid:1378230308.9358.YahooMailNeo@web193904.mail.sg3.yahoo.com"
      type="cite">
      <div style="color:#000; background-color:#fff; font-family:times
        new roman, new york, times, serif;font-size:12pt">
        <div>We are using GlusterFS 3.4.0 and we have a replicated
          volume with one brick each on two real-time servers. For
          certain maintenance purposes, it may be desirable to
          periodically reboot them. During said reboots, we wish to
          umount the brick residing on it. However, umount fails (as
          expected), because of the GlusterFS threads that are using it.
          We thought of the following ways to counter this:<br>
          <br>
          a) Stop the volume, thereby causing its GlusterFS threads to
          terminate. However, this will mean that the other server would
          not be able to access the volume, which will be a problem.<br>
          <br>
          b) Kill the glusterFS threads on the volume, thereby allowing
          umount to proceed. However, I am given to understand that this
          method is not very graceful, and may lead to data loss in case
          some local modifications have not synced onto the other
          server.<br>
          <br>
          c) Delete the brick from the volume, remove its
          "trusted.glusterfs.volume-id", and then re-add it once the
          server comes back up. <br>
          <br>
          Could you &nbsp;help me with some advice on what would be the best
          way to do it?</div>
        <div style="color: rgb(0, 0, 0); font-size: 13px; font-family:
          'times new roman', 'new york', times, serif; background-color:
          transparent; font-style: italic;"><br>
        </div>
        <br>
      </div>
    </blockquote>
    The brick service is glusterfsd so that's what'll need killed. What
    I like to do is:<br>
    <br>
    Kill the brick services for that brick. I, personally, use pkill -f
    $brick_path since the only application I have running that has the
    brick path in the command options is glusterfsd. Do no "pkill -9".
    This will terminate glusterfsd without shutting down the TCP
    connections leading to your clients hanging for ping-timeout
    seconds.<br>
    <br>
    Perform your maintenance.<br>
    <br>
    Start the brick(s) for that volume again with "gluster volume start
    $vol force".<br>
    <br>
    Any files that were changed during the downtime will be self-healed.<br>
  </body>
</html>