<div dir="ltr"><div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Fri, Feb 9, 2018 at 4:30 PM Raghavendra Gowdappa &lt;<a href="mailto:rgowdapp@redhat.com">rgowdapp@redhat.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><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>
&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>
&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>
+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></blockquote><div><br>There has been some progress on this. Details can be found at:<br><a href="https://www.mail-archive.com/gluster-devel@gluster.org/msg14877.html">https://www.mail-archive.com/gluster-devel@gluster.org/msg14877.html</a><br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<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/show_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/latest/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/show_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/show_bug.cgi?id=1390050</a><br>
&gt; <br>
&gt; regards,<br>
&gt; Raghavendra<br>
&gt; _______________________________________________<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/mailman/listinfo/gluster-devel</a><br>
&gt; <br>
&gt; <br>
&gt; _______________________________________________<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/mailman/listinfo/gluster-devel</a><br>
&gt; <br>
&gt; <br>
&gt; <br>
&gt; --<br>
&gt; Raghavendra G<br>
&gt; <br>
&gt; _______________________________________________<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/mailman/listinfo/gluster-devel</a><br>
&gt; <br>
&gt; <br>
&gt; <br>
&gt; --<br>
&gt; Pranith<br>
&gt; <br>
&gt; _______________________________________________<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/mailman/listinfo/gluster-devel</a><br>
_______________________________________________<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/mailman/listinfo/gluster-devel</a><br>
</blockquote></div></div></div>