<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 14, 2018 at 10:31 PM, Amar Tumballi <span dir="ltr">&lt;<a href="mailto:atumball@redhat.com" target="_blank">atumball@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Top posting as it is not exactly about in-consistency of perf layer.</div><div><br></div>On the performance translators of Gluster, I am more interested to get work done on write-back caching layer, specially with using lease feature. Mainly because there are way too many usecases where a given directory would be used only by one client/application at the time.</div></blockquote><div><br></div><div>Can you explain a bit more in detail? Is it the problem of cached writes reaching bricks after a lease is revoked (but application writes were done when there was a valid lease)?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>Regards,</div><div>Amar</div><div><br><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">On Wed, Feb 14, 2018 at 8:17 AM, Raghavendra G <span dir="ltr">&lt;<a href="mailto:raghavendra@gluster.com" target="_blank">raghavendra@gluster.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I&#39;ve started marking &quot;whiteboard&quot; of bugs in this class with tag &quot;GLUSTERFS_METADATA_INCONSISTE<wbr>NCY&quot;. Please add the tag to any bugs which you deem to fit in.<br></div><div class="gmail_extra"><div><div class="m_-4437104229530686558h5"><br><div class="gmail_quote">On Fri, Feb 9, 2018 at 4:30 PM, Raghavendra Gowdappa <span dir="ltr">&lt;<a href="mailto:rgowdapp@redhat.com" target="_blank">rgowdapp@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><br>
<br>
----- Original Message -----<br>
&gt; From: &quot;Pranith Kumar Karampuri&quot; &lt;<a href="mailto:pkarampu@redhat.com" target="_blank">pkarampu@redhat.com</a>&gt;<br>
&gt; To: &quot;Raghavendra G&quot; &lt;<a href="mailto:raghavendra@gluster.com" target="_blank">raghavendra@gluster.com</a>&gt;<br>
</span><span>&gt; Cc: &quot;Gluster Devel&quot; &lt;<a href="mailto:gluster-devel@gluster.org" target="_blank">gluster-devel@gluster.org</a>&gt;<br>
&gt; Sent: Friday, February 9, 2018 2:30:59 PM<br>
&gt; Subject: Re: [Gluster-devel] Glusterfs and Structured data<br>
&gt;<br>
&gt;<br>
&gt;<br>
</span><div><div class="m_-4437104229530686558m_-9216210942304039097h5">&gt; On Thu, Feb 8, 2018 at 12:05 PM, Raghavendra G &lt; <a href="mailto:raghavendra@gluster.com" target="_blank">raghavendra@gluster.com</a> &gt;<br>
&gt; wrote:<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; On Tue, Feb 6, 2018 at 8:15 PM, Vijay Bellur &lt; <a href="mailto:vbellur@redhat.com" target="_blank">vbellur@redhat.com</a> &gt; wrote:<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; On Sun, Feb 4, 2018 at 3:39 AM, Raghavendra Gowdappa &lt; <a href="mailto:rgowdapp@redhat.com" target="_blank">rgowdapp@redhat.com</a> &gt;<br>
&gt; wrote:<br>
&gt;<br>
&gt;<br>
&gt; All,<br>
&gt;<br>
&gt; One of our users pointed out to the documentation that glusterfs is not good<br>
&gt; for storing &quot;Structured data&quot; [1], while discussing an issue [2].<br>
&gt;<br>
&gt;<br>
&gt; As far as I remember, the content around structured data in the Install Guide<br>
&gt; is from a FAQ that was being circulated in Gluster, Inc. indicating the<br>
&gt; startup&#39;s market positioning. Most of that was based on not wanting to get<br>
&gt; into performance based comparisons of storage systems that are frequently<br>
&gt; seen in the structured data space.<br>
&gt;<br>
&gt;<br>
&gt; Does any of you have more context on the feasibility of storing &quot;structured<br>
&gt; data&quot; on Glusterfs? Is one of the reasons for such a suggestion &quot;staleness<br>
&gt; of metadata&quot; as encountered in bugs like [3]?<br>
&gt;<br>
&gt;<br>
&gt; There are challenges that distributed storage systems face when exposed to<br>
&gt; applications that were written for a local filesystem interface. We have<br>
&gt; encountered problems with applications like tar [4] that are not in the<br>
&gt; realm of &quot;Structured data&quot;. If we look at the common theme across all these<br>
&gt; problems, it is related to metadata &amp; read after write consistency issues<br>
&gt; with the default translator stack that gets exposed on the client side.<br>
&gt; While the default stack is optimal for other scenarios, it does seem that a<br>
&gt; category of applications needing strict metadata consistency is not well<br>
&gt; served by that. We have observed that disabling a few performance<br>
&gt; translators and tuning cache timeouts for VFS/FUSE have helped to overcome<br>
&gt; some of them. The WIP effort on timestamp consistency across the translator<br>
&gt; stack, patches that have been merged as a result of the bugs that you<br>
&gt; mention &amp; other fixes for outstanding issues should certainly help in<br>
&gt; catering to these workloads better with the file interface.<br>
&gt;<br>
&gt; There are deployments that I have come across where glusterfs is used for<br>
&gt; storing structured data. gluster-block &amp; qemu-libgfapi overcome the metadata<br>
&gt; consistency problem by exposing a file as a block device &amp; by disabling most<br>
&gt; of the performance translators in the default stack. Workloads that have<br>
&gt; been deemed problematic with the file interface for the reasons alluded<br>
&gt; above, function well with the block interface.<br>
&gt;<br>
&gt; I agree that gluster-block due to its usage of a subset of glusterfs fops<br>
&gt; (mostly reads/writes I guess), runs into less number of consistency issues.<br>
&gt; However, as you&#39;ve mentioned we seem to disable perf xlator stack in our<br>
&gt; tests/use-cases till now. Note that perf xlator stack is one of worst<br>
&gt; offenders as far as the metadata consistency is concerned (relatively less<br>
&gt; scenarios of data inconsistency). So, I wonder,<br>
&gt; * what would be the scenario if we enable perf xlator stack for<br>
&gt; gluster-block?<br>
&gt; * Is performance on gluster-block satisfactory so that we don&#39;t need these<br>
&gt; xlators?<br>
&gt; - Or is it that these xlators are not useful for the workload usually run on<br>
&gt; gluster-block (For random read/write workload, read/write caching xlators<br>
&gt; offer less or no advantage)?<br>
&gt;<br>
&gt; Yes. They are not useful. Block/VM files are opened with O_DIRECT, so we<br>
&gt; don&#39;t enable caching at any layer in glusterfs. md-cache could be useful for<br>
&gt; serving fstat from glusterfs. But apart from that I don&#39;t see any other<br>
&gt; xlator contributing much.<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; - Or theoretically the workload is ought to benefit from perf xlators, but we<br>
&gt; don&#39;t see them in our results (there are open bugs to this effect)?<br>
&gt;<br>
&gt; I am asking these questions to ascertain priority on fixing perf xlators for<br>
&gt; (meta)data inconsistencies. If we offer a different solution for these<br>
&gt; workloads, the need for fixing these issues will be less.<br>
&gt;<br>
&gt; My personal opinion is that both block and fs should work correctly. i.e.<br>
&gt; caching xlators shouldn&#39;t lead to inconsistency issues.<br>
<br>
</div></div>+1. That&#39;s my personal opinion too. We&#39;ll try to fix these issues. However, we need to qualify the fixes. It would be helpful if community can help here. We&#39;ll let community know when the fixes are in.<br>
<div class="m_-4437104229530686558m_-9216210942304039097HOEnZb"><div class="m_-4437104229530686558m_-9216210942304039097h5"><br>
&gt; It would be better<br>
&gt; if we are in a position where we choose a workload on block vs fs based on<br>
&gt; their performance for that workload and nothing else. Block/VM usecases<br>
&gt; change the workload of the application for glusterfs, so for small file<br>
&gt; operations the kind of performance you see on block can never be achieved by<br>
&gt; glusterfs with the current architecture/design.<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; I feel that we have come a long way from the time the install guide was<br>
&gt; written and an update for removing the &quot;staleness of content&quot; might be in<br>
&gt; order there :-).<br>
&gt;<br>
&gt; Regards,<br>
&gt; Vijay<br>
&gt;<br>
&gt; [4] <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1058526" rel="noreferrer" target="_blank">https://bugzilla.redhat.com/sh<wbr>ow_bug.cgi?id=1058526</a><br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; [1] <a href="http://docs.gluster.org/en/latest/Install-Guide/Overview/" rel="noreferrer" target="_blank">http://docs.gluster.org/en/lat<wbr>est/Install-Guide/Overview/</a><br>
&gt; [2] <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1512691" rel="noreferrer" target="_blank">https://bugzilla.redhat.com/sh<wbr>ow_bug.cgi?id=1512691</a><br>
&gt; [3] <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1390050" rel="noreferrer" target="_blank">https://bugzilla.redhat.com/sh<wbr>ow_bug.cgi?id=1390050</a><br>
&gt;<br>
&gt; regards,<br>
&gt; Raghavendra<br>
&gt; ______________________________<wbr>_________________<br>
&gt; Gluster-devel mailing list<br>
&gt; <a href="mailto:Gluster-devel@gluster.org" target="_blank">Gluster-devel@gluster.org</a><br>
&gt; <a href="http://lists.gluster.org/mailman/listinfo/gluster-devel" rel="noreferrer" target="_blank">http://lists.gluster.org/mailm<wbr>an/listinfo/gluster-devel</a><br>
&gt;<br>
&gt;<br>
&gt; ______________________________<wbr>_________________<br>
&gt; Gluster-devel mailing list<br>
&gt; <a href="mailto:Gluster-devel@gluster.org" target="_blank">Gluster-devel@gluster.org</a><br>
&gt; <a href="http://lists.gluster.org/mailman/listinfo/gluster-devel" rel="noreferrer" target="_blank">http://lists.gluster.org/mailm<wbr>an/listinfo/gluster-devel</a><br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; --<br>
&gt; Raghavendra G<br>
&gt;<br>
&gt; ______________________________<wbr>_________________<br>
&gt; Gluster-devel mailing list<br>
&gt; <a href="mailto:Gluster-devel@gluster.org" target="_blank">Gluster-devel@gluster.org</a><br>
&gt; <a href="http://lists.gluster.org/mailman/listinfo/gluster-devel" rel="noreferrer" target="_blank">http://lists.gluster.org/mailm<wbr>an/listinfo/gluster-devel</a><br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; --<br>
&gt; Pranith<br>
&gt;<br>
&gt; ______________________________<wbr>_________________<br>
&gt; Gluster-devel mailing list<br>
&gt; <a href="mailto:Gluster-devel@gluster.org" target="_blank">Gluster-devel@gluster.org</a><br>
&gt; <a href="http://lists.gluster.org/mailman/listinfo/gluster-devel" rel="noreferrer" target="_blank">http://lists.gluster.org/mailm<wbr>an/listinfo/gluster-devel</a><br>
______________________________<wbr>_________________<br>
Gluster-devel mailing list<br>
<a href="mailto:Gluster-devel@gluster.org" target="_blank">Gluster-devel@gluster.org</a><br>
<a href="http://lists.gluster.org/mailman/listinfo/gluster-devel" rel="noreferrer" target="_blank">http://lists.gluster.org/mailm<wbr>an/listinfo/gluster-devel</a><br>
</div></div></blockquote></div><br><br clear="all"><br></div></div><span class="m_-4437104229530686558HOEnZb"><font color="#888888">-- <br><div class="m_-4437104229530686558m_-9216210942304039097gmail_signature" data-smartmail="gmail_signature">Raghavendra G<br></div>
</font></span></div>
<br>______________________________<wbr>_________________<br>
Gluster-devel mailing list<br>
<a href="mailto:Gluster-devel@gluster.org" target="_blank">Gluster-devel@gluster.org</a><br>
<a href="http://lists.gluster.org/mailman/listinfo/gluster-devel" rel="noreferrer" target="_blank">http://lists.gluster.org/mailm<wbr>an/listinfo/gluster-devel</a><br></blockquote></div><br><br clear="all"><div><br></div>-- <br></div></div><div class="m_-4437104229530686558gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Amar Tumballi (amarts)<br></div></div></div></div></div>
</div></div></div>
</blockquote></div><br></div></div>