<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 22, 2017 at 11:49 AM, Joe Julian <span dir="ltr"><<a href="mailto:joe@julianfamily.org" target="_blank">joe@julianfamily.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>This may be asking too much, but can you explain why or how it's even possible to bypass the cache like this, Vijay?</div></blockquote><div><br></div><div>This is a good question and the answers to that is something I should have elaborated a bit more in my previous response. As far as the why is concerned, gluster's client stack is configured by default to provide reasonable performance and not be very strongly consistent for applications that need the most accurate metadata for their functioning. Turning off the performance translators provide more stronger consistency and we have seen applications that rely on a high degree of consistency work better with that configuration. It is with this backdrop I suggested performance translators be turned off from the client stack for Kafka.</div><div><br></div><div>On how it is possible, the translator model of gluster helps us to enable or disable optional functionality from the stack. There is no single configuration that can accommodate workloads with varying profiles and having a modular architecture is a plus for gluster - the storage stack can be tuned to suit varying application profiles. We are exploring the possibility of providing custom profiles (collections of options) for popular applications to make it easier for all of us. Note that disabling performance translators in gluster is similar to turning off caching with the NFS client. In parallel we are also looking to alter the behavior of performance translators to provide as much consistency as possible by default.</div><div><br></div><div>Thanks,</div><div>Vijay</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div class="m_8195164867435537042m_2021887885306548806h5">
<br><br><div class="gmail_quote">On May 22, 2017 7:41:40 AM PDT, Vijay Bellur <<a href="mailto:vbellur@redhat.com" target="_blank">vbellur@redhat.com</a>> wrote:<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">Looks like a problem with caching. Can you please try by disabling all performance translators? The following configuration commands would disable performance translators in the gluster client stack: <div><span style="color:rgb(0,0,0);white-space:pre-wrap"><br></span></div><div><span style="color:rgb(0,0,0);white-space:pre-wrap">gluster volume set <volname> performance.quick-read off</span></div><div><span style="color:rgb(0,0,0);white-space:pre-wrap">gluster volume set <volname> performance.io-cache off</span></div><div><span style="color:rgb(0,0,0);white-space:pre-wrap">gluster volume set <volname> performance.write-behind off</span></div><div><span style="color:rgb(0,0,0);white-space:pre-wrap">gluster volume set <volname> performance.stat-prefetch off</span></div><div><span style="color:rgb(0,0,0);white-space:pre-wrap">gluster volume set <volname> performance.read-ahead off</span></div><div><span style="color:rgb(0,0,0);white-space:pre-wrap">gluster volume set <volname> performance.readdir-ahead off</span></div><div><span style="color:rgb(0,0,0);white-space:pre-wrap">gluster volume set <volname> performance.open-behind off</span></div><div><span style="color:rgb(0,0,0);white-space:pre-wrap">gluster volume set <volname> performance.client-io-threads off</span></div><div><span style="color:rgb(0,0,0);white-space:pre-wrap"><br></span></div><div><span style="color:rgb(0,0,0);white-space:pre-wrap">Thanks,</span></div><div><span style="color:rgb(0,0,0);white-space:pre-wrap">Vijay</span></div><div><pre class="m_8195164867435537042m_2021887885306548806m_2828103646518558289gmail-bz_comment_text m_8195164867435537042m_2021887885306548806m_2828103646518558289gmail-bz_wrap_comment_text" id="m_8195164867435537042m_2021887885306548806m_2828103646518558289gmail-comment_text_50" style="white-space:pre-wrap;word-wrap:break-word;width:50em;color:rgb(0,0,0)"><br></pre></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 22, 2017 at 9:46 AM, Christopher Schmidt <span dir="ltr"><<a href="mailto:fakod666@gmail.com" target="_blank">fakod666@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi all,<div><br></div><div>has anyone ever successfully deployed a Kafka (Cluster) on GlusterFS volumes?</div><div><br></div><div>I my case it's a Kafka Kubernetes-StatefulSet and a Heketi GlusterFS.</div><div>Needless to say that I am getting a lot of filesystem related exceptions like this one:</div><div><br></div><div>Failed to read `log header` from file channel `sun.nio.ch.FileChannelImpl@67<wbr>afa54a`. Expected to read 12 bytes, but reached end of file after reading 0 bytes. Started read from position 123065680.<br></div><div><br></div><div>I limited the amount of exceptions with the log.flush.interval.message<wbr>s=1 option, but not all...</div><div><br></div><div>best Christopher</div><div><br></div></div>
<br>______________________________<wbr>_________________<br>
Gluster-users mailing list<br>
<a href="mailto:Gluster-users@gluster.org" target="_blank">Gluster-users@gluster.org</a><br>
<a href="http://lists.gluster.org/mailman/listinfo/gluster-users" rel="noreferrer" target="_blank">http://lists.gluster.org/mailm<wbr>an/listinfo/gluster-users</a><br></blockquote></div><br></div></div>
</blockquote></div><br></div></div><span class="m_8195164867435537042m_2021887885306548806HOEnZb"><font color="#888888">
-- <br>
Sent from my Android device with K-9 Mail. Please excuse my brevity.</font></span></div></blockquote></div><br></div></div>