<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr">On Wed, Jun 13, 2018, 5:22 AM Vijay Bellur <<a href="mailto:vbellur@redhat.com">vbellur@redhat.com</a>> wrote:<br></div><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">On Mon, Jun 11, 2018 at 7:44 PM, Raghavendra Gowdappa <span dir="ltr"><<a href="mailto:rgowdapp@redhat.com" target="_blank" rel="noreferrer">rgowdapp@redhat.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"><div><div><div>All,<br></div><div><br></div>This is an option in open-behind, which lets fuse native mounts to use anonymous fds. The reasoning being since anonymous fds are stateless, overhead of open is avoided and hence better performance. However, bugs filed [1][2] seemed to indicate contrary results.<br><br>Also, using anonymous fds affects other xlators which rely on per fd state [3].<br><br>So, this brings to the point do anonymous-fds actually improve performance on native fuse mounts? If not, we can disable them. May be they are useful for light weight metadata operations like fstat, but the workload should only be limited to them. Note that anonymous fds are used by open-behind by only two fops - readv and fstat. But, [1] has shown that they actually regress performance for sequential reads.<br></div></div></div></blockquote><div><br></div><div><br></div><div>Perhaps a more intelligent open-behind based on size could help? IIRC, open-behind was originally developed to improve latency for small file operations. For large files, it is unnecessary and can affect read-ahead behavior as observed in the referenced bugs. Could we alter the behavior to disable open-behind for those files which are bigger than a configurable size threshold?</div></div></div></div></blockquote></div></div><div dir="auto">+1, this sounds like a perfect solution which doesn't give out the benefits (may be in few cases) but also doesn't reduce the performance in small file read. We could enable open behind only for fd with rd-only, and if the size is less than or equal to the quick-read file size.</div><div dir="auto"><br></div><div dir="auto">Regards,</div><div dir="auto">Poornima</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><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><br></div><div>Thanks,</div><div>Vijay</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><div><br>[1] <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1419807" target="_blank" rel="noreferrer">https://bugzilla.redhat.com/show_bug.cgi?id=1419807</a><br>[2] <a href="https://bugzilla.redhat.com/1489513" target="_blank" rel="noreferrer">https://bugzilla.redhat.com/1489513</a>, "read-ahead underperrforms expectations"<br> open-behind without patch (MiB/s) with patch (MiB/s)<br> on 132.87 133.51<br> off 139.70 139.77<br><br>[3] <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1084508" target="_blank" rel="noreferrer">https://bugzilla.redhat.com/show_bug.cgi?id=1084508</a><br></div><div><br></div><div>PS: Anonymous fds are stateless fds, where a client like native fuse mount doesn't do an explicit open. Instead, bricks do the open on-demand during fops which need an fd (like readv, fstat etc).<br></div><div><br></div>regards,<br></div>Raghavendra<br></div>
<br>_______________________________________________<br>
Gluster-devel mailing list<br>
<a href="mailto:Gluster-devel@gluster.org" target="_blank" rel="noreferrer">Gluster-devel@gluster.org</a><br>
<a href="http://lists.gluster.org/mailman/listinfo/gluster-devel" rel="noreferrer noreferrer" target="_blank">http://lists.gluster.org/mailman/listinfo/gluster-devel</a><br></blockquote></div><br></div></div>
_______________________________________________<br>
Gluster-devel mailing list<br>
<a href="mailto:Gluster-devel@gluster.org" target="_blank" rel="noreferrer">Gluster-devel@gluster.org</a><br>
<a href="http://lists.gluster.org/mailman/listinfo/gluster-devel" rel="noreferrer noreferrer" target="_blank">http://lists.gluster.org/mailman/listinfo/gluster-devel</a></blockquote></div></div></div>