<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <p>Sorry, missing lines from the attachment.<br>
    </p>
    <br>
    <div class="moz-cite-prefix">On 05/04/2017 03:24 PM, Miklós Fokin
      wrote:<br>
    </div>
    <blockquote
      cite="mid:5b6becad-d795-96f6-6671-66a23fb83d0d@appeartv.com"
      type="cite">Hello,
      <br>
      <br>
      I seem to have discovered what caused half of the problem.
      <br>
      I did update the bug report with a more detailed description, but
      the short version is that the attached diff solves the issue when
      we get an fstat with a size of 0 after killing a brick (not
      letting the first update to fsync be from an arbiter).
      <br>
      My question is: should I make a review about it or should further
      needed changes be investigated first?
      <br>
      <br>
      Best regards,
      <br>
      Miklós
      <br>
      <br>
      <br>
      On 04/26/2017 12:58 PM, Miklós Fokin wrote:
      <br>
      <blockquote type="cite">Thanks for the response.
        <br>
        We didn't have the options set that the first two reviews were
        about.
        <br>
        The third was about changes to performance.readdir-ahead.
        <br>
        I turned this feature off today with prefetch being turned on on
        my computer, and the bug still appeared, so I would think that
        the commit would not fix it either.
        <br>
        <br>
        Best regards,
        <br>
        Miklós
        <br>
        <br>
        <br>
        On 04/25/2017 01:26 PM, Raghavendra Gowdappa wrote:
        <br>
        <blockquote type="cite">Recently we had worked on some patches
          to ensure correct stats are returned.
          <br>
          <br>
          <a class="moz-txt-link-freetext" href="https://review.gluster.org/15759">https://review.gluster.org/15759</a>
          <br>
          <a class="moz-txt-link-freetext" href="https://review.gluster.org/15659">https://review.gluster.org/15659</a>
          <br>
          <a class="moz-txt-link-freetext" href="https://review.gluster.org/16419">https://review.gluster.org/16419</a>
          <br>
          <br>
          Referring to these patches and bugs associated with them might
          give you some insight into the nature of the problem. The
          major culprit was interaction between readdir-ahead and
          stat-prefetch. So, the issue you are seeing might be addressed
          by these patches.
          <br>
          <br>
          ----- Original Message -----
          <br>
          <blockquote type="cite">From: "Miklós Fokin"
            <a class="moz-txt-link-rfc2396E" href="mailto:miklos.fokin@appeartv.com">&lt;miklos.fokin@appeartv.com&gt;</a>
            <br>
            To: <a class="moz-txt-link-abbreviated" href="mailto:gluster-devel@gluster.org">gluster-devel@gluster.org</a>
            <br>
            Sent: Tuesday, April 25, 2017 3:42:52 PM
            <br>
            Subject: [Gluster-devel] fstat problems when killing with
            stat prefetch    turned on
            <br>
            <br>
            Hello,
            <br>
            <br>
            I tried reproducing the problem that Mateusz Slupny was
            experiencing
            <br>
            before (stat returning bad st_size value on self-healing) on
            my own
            <br>
            computer with only 3 bricks (one being an arbiter) on
            3.10.0.
            <br>
            The result with such a small setup was that the bug appeared
            both on
            <br>
            killing and during the self-healing process, but only rarely
            (once in
            <br>
            hundreds of tries) and only with performance.stat-prefetch
            turned on.
            <br>
            This might be a completely different issue as on the setup
            Matt was
            <br>
            using, he could reproduce it with the mentioned option being
            off, it
            <br>
            always happened but only during recovery, not after killing.
            <br>
            I did submit a bug report about this:
            <br>
            <a class="moz-txt-link-freetext" href="https://bugzilla.redhat.com/show_bug.cgi?id=1444892">https://bugzilla.redhat.com/show_bug.cgi?id=1444892</a>.
            <br>
            <br>
            The problem is as Matt wrote is that this causes data
            corruption if one
            <br>
            is to use the returned size on writing.
            <br>
            Could I get some pointers as to what parts of the gluster
            code I should
            <br>
            be looking at to figure out what the problem might be?
            <br>
            <br>
            Thanks in advance,
            <br>
            Miklós
            <br>
            <br>
            _______________________________________________
            <br>
            Gluster-devel mailing list
            <br>
            <a class="moz-txt-link-abbreviated" href="mailto:Gluster-devel@gluster.org">Gluster-devel@gluster.org</a>
            <br>
            <a class="moz-txt-link-freetext" href="http://lists.gluster.org/mailman/listinfo/gluster-devel">http://lists.gluster.org/mailman/listinfo/gluster-devel</a>
            <br>
          </blockquote>
        </blockquote>
        <br>
      </blockquote>
      <br>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Gluster-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Gluster-devel@gluster.org">Gluster-devel@gluster.org</a>
<a class="moz-txt-link-freetext" href="http://lists.gluster.org/mailman/listinfo/gluster-devel">http://lists.gluster.org/mailman/listinfo/gluster-devel</a></pre>
    </blockquote>
    <br>
  </body>
</html>