<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 07/28/2016 03:32 PM, Niels de Vos
      wrote:<br>
    </div>
    <blockquote
      cite="mid:20160728100258.GA10950@ndevos-x240.usersys.redhat.com"
      type="cite">
      <pre wrap="">There are some features in QEMU that we could implement with the
existing libgfapi functions. Kevin asked me about this a while back, and
I have finally (sorry for the delay Kevin!) taken the time to look into
it.

There are some optional operations that can be set in the BlockDriver
structure. The ones missing that we could have, or have useless
implementations are these:

  .bdrv_get_info/.bdrv_refresh_limits:
    This seems to set values in a BlockDriverInfo and BlockLimits
    structure that is used by QEMUs block layer. By setting the right
    values, we can use glfs_discard() and glfs_zerofill() to reduce the
    writing of 0-bytes that QEMU falls back on at the moment.

  .bdrv_has_zero_init / qemu_gluster_has_zero_init:
    Currently always returns 0. But if a file gets created on a Gluster
    volume, it should never have old contents in it. Rewriting it with
    0-bytes looks unneeded to me.</pre>
    </blockquote>
    <br>
    <tt>N00b question, what is the need for separate glfs_discard() and
      glfs_zerofill() functions? Can we not just use glfs_fallocate()
      with appropriate flags?</tt><tt><br>
    </tt><tt>posix_discard() in gluster seems to be using fallocate()
      with FALLOC_FL_PUNCH_HOLE flag. And posix_zerofill() can be made
      smarter to use FALLOC_FL_ZERO_RANGE and fallback to writing zeroes
      if ZERO_RANGE is not supported.</tt><tt><br>
      <br>
      Regards,<br>
      Ravi<br>
    </tt><br>
    <blockquote
      cite="mid:20160728100258.GA10950@ndevos-x240.usersys.redhat.com"
      type="cite">
      <pre wrap="">

With these improvements the gluster:// URL usage with QEMU (and now also
the new JSON QAPI), certain operations are expected to be a little
faster. Anyone starting to work on this would want to trace the actual
operations (on a single-brick volume) with ltrace/wireshark on the
system where QEMU runs.

Who is interested to take this on?
Niels
</pre>
      <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://www.gluster.org/mailman/listinfo/gluster-devel">http://www.gluster.org/mailman/listinfo/gluster-devel</a></pre>
    </blockquote>
    <p><br>
    </p>
  </body>
</html>