<div dir="ltr">Thanks Amar! Please see my answers inline.<br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Apr 2, 2018 at 5:41 AM, Amar Tumballi <span dir="ltr"><<a href="mailto:atumball@redhat.com" target="_blank">atumball@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi Riya,<div><br></div><div>Thanks for writing to us. Some questions before we start on this. </div><div><br></div><div>* Where can we see your work of modifying the fuse module to cache the calls? Some reference would help us to provide more specific pointers. (or ask better questions).</div><div><br></div></div></blockquote><div>I've created a fast path framework for FUSE, where the user space daemon can load a module and register handlers for file operations (lookup, open, r/w, etc.) that must be handled in the kernel itself without an up call to the user space. I call them fast path handlers. This design also retains the regular FUSE handlers for file system operations in upser-space (slow path). The fast path and slow path can communicate with each other over shared memory or using syscalls to enable/invalidate caching of data structs (e.g., results of getattr, getxattr, etc.)</div><div> <br></div><div>There's a process I need to follow in order to make the code available publicly. I've already started, but will take some time. I will try to do this asap.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div>* If the caching happened in fuse module, and it expects the regular arguments as the parameters, then there may not be any work required at all in glusterfs, as it works on low-level fuse api.</div><div><br></div></div></blockquote><div><br></div><div>The fast handlers expect same interface and args (fuse_args) as the regular user-space daemon. The fast handler code is fs-specific, therefore, must come from glusterfs. Changes are also needed in glusterfs code to communicate with the fast path for enabling/invalidating caching.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div>* Also, how to invalidate caches from userspace program? because GlusterFS could be accessed from multiple clients, so it becomes an important piece to have.</div><div><br></div></div></blockquote><div><br></div><div>Server invalidate can trigger a system call into the fast path framework to invalidate caches. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div>For referring at the codebase to look at integration with fuse module, please check the directory 'xlators/mount/fuse/src/' and mostly the file 'fuse-bridge.c'.</div><div><br></div><div>Thanks for your interest in project, would be great to collaborate on this effort, as it can enhance the performance of glusterfs in many usecases. </div></div></blockquote><div><br></div><div>I'm still going through gluster developer documentation, but it'd be helpful if you could mention what kind of use cases does the fast/slow split FUSE framework enable? i've already applied the framework to accelerate multiple FUSE-based stackable file systems, but want the interface to be generic enough for all FUSE file systems to take advantage of it.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div>Regards,</div><div>Amar</div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="m_-9184113230290720190gmail-h5">On Mon, Apr 2, 2018 at 6:34 AM, riya khanna <span dir="ltr"><<a href="mailto:riyakhanna1983@gmail.com" target="_blank">riyakhanna1983@gmail.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div><div class="m_-9184113230290720190gmail-h5"><div dir="ltr">Hi,<div><br></div><div><span style="font-size:12.800000190734863px">I've modified FUSE framework to take a part of user-space daemon code and moves it into the kernel fuse driver to minimize user-kernel-user switches during file system operations. An example would be caching getattr/getxattr/lookup/securi<wbr>ty checks etc. This design, therefore, create fast (served directly from the kernel) and a slow (regular fuse) execution paths. The fast and slow paths can also communicate with each other using shared memory.</span></div><div><span style="font-size:12.800000190734863px"><br></span></div><div><span style="font-size:12.800000190734863px">I was wondering if it is possible to accelerate glusterfs using this design. </span><span style="font-size:12.800000190734863px">What pieces could (</span><span style="font-size:12.800000190734863px">should) </span><span style="font-size:12.800000190734863px">be easily moved to kernel space? Any pointers would be highly appreciated. Thanks!</span></div><span class="m_-9184113230290720190gmail-m_1997129897750036374HOEnZb"><font color="#888888"><div><br></div><div><span style="font-size:12.800000190734863px">-Riya</span></div></font></span></div>
<br></div></div>______________________________<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><span class="m_-9184113230290720190gmail-HOEnZb"><font color="#888888"><br></font></span></blockquote></div><span class="m_-9184113230290720190gmail-HOEnZb"><font color="#888888"><br><br clear="all"><div><br></div>-- <br><div class="m_-9184113230290720190gmail-m_1997129897750036374gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Amar Tumballi (amarts)<br></div></div></div></div></div>
</font></span></div>
</blockquote></div><br></div></div>