<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    On 10/21/2012 02:18 PM, Israel Shirk wrote:<br>
    <blockquote
cite="mid:CAF5SWt5C_6UA3hAnjVCFG8AGxyb-axVcbRRmaEz8nB-NLDrrUA@mail.gmail.com"
      type="cite">
      <meta http-equiv="Context-Type" content="text/html;
        charset=ISO-8859-1">
      Haris, try the NFS mount. &nbsp;Gluster typically triggers healing
      through the client, so if you skip the client, nothing heals.</blockquote>
    Not true anymore. With 3.3 there's a self-heal daemon that will
    handle the heals. You do risk reading stale data if you don't read
    through the client though.<br>
    <blockquote
cite="mid:CAF5SWt5C_6UA3hAnjVCFG8AGxyb-axVcbRRmaEz8nB-NLDrrUA@mail.gmail.com"
      type="cite">
      <div>The native Gluster client tends to be really @#$@#$@# stupid.
        &nbsp;It'll send reads to Singapore while you're in Virginia (and
        there are bricks 0.2ms away), </div>
    </blockquote>
    False. The client will read from the first-to-respond. Yes, if
    Singapore is responding faster than Virginia you might want to
    figure out why Virginia is so overloaded that it's taking more than
    200ms to respond, but really that shouldn't be the case.
    <blockquote
cite="mid:CAF5SWt5C_6UA3hAnjVCFG8AGxyb-axVcbRRmaEz8nB-NLDrrUA@mail.gmail.com"
      type="cite">
      <div>then when healing is needed it will take a bunch of time to
        do that, all the while it's blocking your application or web
        server, which under heavy loads will cause your entire
        application to buckle.</div>
    </blockquote>
    False. 3.3 uses granular locking which won't block your application.<br>
    <blockquote
cite="mid:CAF5SWt5C_6UA3hAnjVCFG8AGxyb-axVcbRRmaEz8nB-NLDrrUA@mail.gmail.com"
      type="cite">
      <div>The NFS client is dumb, which in my mind is a lot better -
        it'll just do what you tell it to do and allow you to compensate
        for connectivity issues yourself using something like Linux-HA.<br>
      </div>
    </blockquote>
    The "NFS client" is probably more apt than you meant. It is both
    GlusterFS client and NFS server, and it connects to the bricks and
    performs reads and self-heal in exactly the same way as the fuse
    client.<br>
    <blockquote
cite="mid:CAF5SWt5C_6UA3hAnjVCFG8AGxyb-axVcbRRmaEz8nB-NLDrrUA@mail.gmail.com"
      type="cite">
      <div><br>
        You have to keep in mind when using gluster that 99% of the
        people using it are running their tests on a single server (see
        the recent notes about how testing patches are only performed on
        a single server),</div>
    </blockquote>
    False. There are many more testers than that, most of which are
    outside of the development team.<br>
    <blockquote
cite="mid:CAF5SWt5C_6UA3hAnjVCFG8AGxyb-axVcbRRmaEz8nB-NLDrrUA@mail.gmail.com"
      type="cite">
      <div> and most applications don't distribute or mirror to bricks
        more than a few hundred yards away. &nbsp;Their idea of
        geo-replication is that you send your writes to the other side
        of the world (which may or may not be up at the moment), then
        twiddle your thumbs for a while and hope it gets back to you.
        &nbsp;So, that said, it's possible to get it to work, and it's almost
        better than lsyncd, but it'll still make you cry periodically.</div>
      <div><br>
      </div>
      <div>Ok, back to happy time :)<br>
        <br>
        <div class="gmail_quote">
          <blockquote class="gmail_quote">
            Hi everyone,<br>
            <br>
            I am using Gluster in replication mode.<br>
            Have 3 bricks on 3 different physical servers connected with
            WAN. This<br>
            makes writing but also reading files from Gluster mounted
            volume very slow.<br>
            To remedy this I have made my web application read Gluster
            files from<br>
            the brick directly (I make a readonly bind mount of the
            brick), but<br>
            write to the Gluster FS mounted volume so that the files
            will instantly<br>
            replicate on all 3 servers. At least, "instant replication"
            is what I<br>
            envision GLuster will do for me :)<br>
            <br>
            My problem is that files sometimes do not replicate to all 3
            servers<br>
            instantly. There are certainly short network outages which
            may prevent<br>
            instant replication and I have situations like this:<br>
            <br>
            ssh web1-prod ls -l<br>
            /home/gluster/r/production/<a moz-do-not-send="true"
              href="http://zdrava.tv/web/uploads/24/playlist/38/19_10_2012_18.js"
              target="_blank">zdrava.tv/web/uploads/24/playlist/38/19_10_2012_18.js</a><br>
            -rw-r--r-- 1 apache apache 75901 Oct 19 18:00<br>
            /home/gluster/r/production/<a moz-do-not-send="true"
              href="http://zdrava.tv/web/uploads/24/playlist/38/19_10_2012_18.js"
              target="_blank">zdrava.tv/web/uploads/24/playlist/38/19_10_2012_18.js</a><br>
            web2-prod.<br>
            ssh web2-prod ls -l<br>
            /home/gluster/r/production/<a moz-do-not-send="true"
              href="http://zdrava.tv/web/uploads/24/playlist/38/19_10_2012_18.js"
              target="_blank">zdrava.tv/web/uploads/24/playlist/38/19_10_2012_18.js</a><br>
            -rw-r--r-- 1 apache apache 0 Oct 19 18:00<br>
            /home/gluster/r/production/<a moz-do-not-send="true"
              href="http://zdrava.tv/web/uploads/24/playlist/38/19_10_2012_18.js"
              target="_blank">zdrava.tv/web/uploads/24/playlist/38/19_10_2012_18.js</a><br>
            web3-prod.<br>
            ssh web3-prod ls -l<br>
            /home/gluster/r/production/<a moz-do-not-send="true"
              href="http://zdrava.tv/web/uploads/24/playlist/38/19_10_2012_18.js"
              target="_blank">zdrava.tv/web/uploads/24/playlist/38/19_10_2012_18.js</a><br>
            -rw-r--r--. 1 apache apache 75901 Oct 19 18:00<br>
            /home/gluster/r/production/<a moz-do-not-send="true"
              href="http://zdrava.tv/web/uploads/24/playlist/38/19_10_2012_18.js"
              target="_blank">zdrava.tv/web/uploads/24/playlist/38/19_10_2012_18.js</a><br>
            <br>
            Where the file on web2 server brick has a size of 0. So
            serving this<br>
            file from web2 makes my application make errors..<br>
            <br>
            I have had a brain-split situation couple of times and
            resolved<br>
            manually. The above kind of situation is not a brain-split
            and resolves<br>
            and (re-)replicates completly with a simple "ls -l" on the
            file in<br>
            question from any of the servers.<br>
            <br>
            My question is:<br>
            I suppose that the problem here is incomplete replication
            for the file<br>
            in question due to temporary network problems.<br>
            How to insure the complete replication immediatly after the
            network has<br>
            been restored?<br>
            <br>
            <br>
            kind regards<br>
            Haris Zukanovic<br>
            <br>
            --<br>
            --<br>
            Haris Zukanovic<br>
            <br>
          </blockquote>
        </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://supercolony.gluster.org/mailman/listinfo/gluster-users">http://supercolony.gluster.org/mailman/listinfo/gluster-users</a></pre>
    </blockquote>
    <br>
  </body>
</html>