<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 29 June 2018 at 13:02, 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"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Fri, Jun 29, 2018 at 12:25 PM, Vijay Bellur <span dir="ltr">&lt;<a href="mailto:vbellur@redhat.com" target="_blank">vbellur@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"><br><br><div class="gmail_quote"><span><div dir="ltr">On Wed, Jun 27, 2018 at 10:15 PM Raghavendra Gowdappa &lt;<a href="mailto:rgowdapp@redhat.com" target="_blank">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"><div dir="ltr"><div>All,<br><br>There is a requirement in write-behind where during readdirp we may have to invalidate iatts/stats of some of the children of the directory [1]. For lack of better alternatives I added a dentry list to parent inode which contains all children that&#39;ve been linked (through lookup or readdirp on directory). I myself am not too comfortable with this solution as it might eat up significant memory for large directories.<br><br></div>Thoughts?<br></div></blockquote><div><br></div><div><br></div></span><div>Reading [2] makes me wonder if write-behind is the appropriate place for this change. Shouldn&#39;t md-cache be made aware of inode generations or something similar?</div><div><br></div></div></div></blockquote><div><br></div></span><div>Thanks for the pointers Vijay. But, now what happens if user keeps write-behind and turns off md-cache? (like virt profile and block profile).</div><div><br></div><div>Raghavendra, while this patch fixes the problem specific to the usecase, all these changes break the boundary of translators, which were supposed to deal with just 1 fop (or one feature). </div><div><br></div><div>It makes sense for us to move towards a global &#39;caching&#39; xlator which can give better performance,  and has visibility to all the information about the file, and all fop. That will reduce all this complexity of what should be done for certain specific cases, type of problems.<br></div></div></div></div></blockquote><div>+1 </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div><br></div><div>Also, is there any performance numbers possible with this patch and without this patch in regular readdirp operations ?</div><div><br></div><div>Regards,</div><div>Amar</div><span class=""><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 class="gmail_quote"><div></div><div>Thanks,</div><div>Vijay</div><div><br></div><div>[2] <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1512691#c18" target="_blank">https://bugzilla.redhat.co<wbr>m/show_bug.cgi?id=1512691#c18</a></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span><div dir="ltr"><div><br>[1] <a href="https://review.gluster.org/20413" target="_blank">https://review.gluster.org/204<wbr>13</a></div><div><br></div><div>regards,</div><div>Raghavendra<br></div></div></span>
______________________________<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></blockquote></div></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></span></div><span class="HOEnZb"><font color="#888888"><br><br clear="all"><div><br></div>-- <br><div class="m_2395574033147381005gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Amar Tumballi (amarts)<br></div></div></div></div></div>
</font></span></div></div>
<br>______________________________<wbr>_________________<br>
Gluster-devel mailing list<br>
<a href="mailto:Gluster-devel@gluster.org">Gluster-devel@gluster.org</a><br>
<a href="http://lists.gluster.org/mailman/listinfo/gluster-devel" rel="noreferrer" target="_blank">http://lists.gluster.org/<wbr>mailman/listinfo/gluster-devel</a><br></blockquote></div><br></div></div>