<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Jul 13, 2019 at 7:33 AM Emmanuel Dreyfus <<a href="mailto:manu@netbsd.org">manu@netbsd.org</a>> 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">Hello<br>
<br>
I have trouble figuring the whole story about how to cope with FUSE<br>
directory filehandles in the NetBSD implementation.<br>
<br>
libfuse makes a special use of filehandles exposed to filesystem for<br>
OPENDIR, READDIR, FSYNCDIR, and RELEASEDIR. For that four operations,<br>
the fh is a pointer to a struct fuse_dh, in which the fh field is<br>
exposed to the filesystem. All other filesystem operations pass the fh<br>
as is from kernel to filesystem back and forth.<br>
<br>
That means that a fh obtained by OPENDIR should never be passed to<br>
operations others than (READDIR, FSYNCDIR and RELEASEDIR). For instance,<br>
when porting ltfs to NetBSD, I experienced that passing a fh obtained<br>
from OPENDIR to SETATTR would crash.<br>
<br>
glusterfs implementation differs from libfuse because it seems the<br>
filesystem is always passed as is: there is nothing like libfuse struct<br>
fuse_dh. It will therefore happily accept fh obtained by OPENDIR for any<br>
operation, something that I do not expect to happen in libfuse based<br>
filesystems.<br>
<br></blockquote><div><br></div><div>It would be great to add these comments as part of <a href="https://github.com/gluster/glusterfs/issues/153">https://github.com/gluster/glusterfs/issues/153</a>. My take is to start working in the direction of rebasing gluster code to use libfuse in future than to maintain our own changes. Would that help if we move in that direction?</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">
My real concern is SETLK on directory. Here glusterfs really wants a fh<br>
or it will report an error. The NetBSD implementation passes the fh it<br>
got from OPENDIR, but I expect a libfuse based filesystem to crash in<br>
such a situation. For now I did not find any libfuse-based filesystem<br>
that implements locking, so I could not test that. <br>
<br>
Could someone clarify this? What are the FUSE operations that should be<br>
sent to filesystem on that kind of program?<br>
<br>
int fd;<br>
<br>
/* NetBSD calls FUSE LOOKUP and OPENDIR */<br>
if ((fd = open("/gfs/tmp", O_RDONLY, 0)) == -1)<br>
err(1, "open failed");<br>
<br>
/* NetBSD calls FUSE SETLKW */<br>
if (flock(fd, LOCK_EX) == -1)<br>
err(1, "flock failed");<br>
<br></blockquote><div><br></div><div>Csaba, Raghavendra, Any suggestions here?</div><div><br></div><div>-Amar</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">
<br>
<br>
-- <br>
Emmanuel Dreyfus<br>
<a href="http://hcpnet.free.fr/pubz" rel="noreferrer" target="_blank">http://hcpnet.free.fr/pubz</a><br>
<a href="mailto:manu@netbsd.org" target="_blank">manu@netbsd.org</a><br>
_______________________________________________<br>
<br>
Community Meeting Calendar:<br>
<br>
APAC Schedule -<br>
Every 2nd and 4th Tuesday at 11:30 AM IST<br>
Bridge: <a href="https://bluejeans.com/836554017" rel="noreferrer" target="_blank">https://bluejeans.com/836554017</a><br>
<br>
NA/EMEA Schedule -<br>
Every 1st and 3rd Tuesday at 01:00 PM EDT<br>
Bridge: <a href="https://bluejeans.com/486278655" rel="noreferrer" target="_blank">https://bluejeans.com/486278655</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="https://lists.gluster.org/mailman/listinfo/gluster-devel" rel="noreferrer" target="_blank">https://lists.gluster.org/mailman/listinfo/gluster-devel</a><br>
<br>
</blockquote></div></div>