directory filehandles

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

directory filehandles

Emmanuel Dreyfus
Hello

I have trouble figuring the whole story about how to cope with FUSE
directory filehandles in the NetBSD implementation.

libfuse makes a special use of filehandles exposed to filesystem for
OPENDIR, READDIR, FSYNCDIR, and RELEASEDIR. For that four operations,
the fh is a pointer to a struct fuse_dh, in which the fh field is
exposed to the filesystem. All other filesystem operations pass the fh
as is from kernel to filesystem back and forth.

That means that a fh obtained by OPENDIR should never be passed to
operations others than (READDIR, FSYNCDIR and RELEASEDIR). For instance,
when porting ltfs to NetBSD, I experienced that passing a fh obtained
from OPENDIR to SETATTR would crash.

glusterfs implementation differs from libfuse because it seems the
filesystem is always passed as is: there is nothing like libfuse struct
fuse_dh. It will therefore happily accept fh obtained by OPENDIR for any
operation, something that I do not expect to happen in libfuse based
filesystems.

My real concern is SETLK on directory. Here glusterfs really wants a fh
or it will report an error. The NetBSD implementation passes the fh it
got from OPENDIR, but I expect a libfuse based filesystem to crash in
such a situation. For now I did not find any libfuse-based filesystem
that implements locking, so I could not test that.

Could someone clarify this? What are the FUSE operations that should be
sent to filesystem on that kind of program?

        int fd;

        /* NetBSD  calls FUSE LOOKUP and OPENDIR */
        if ((fd = open("/gfs/tmp", O_RDONLY, 0)) == -1)
                err(1, "open failed");

        /* NetBSD calls FUSE SETLKW */
        if (flock(fd, LOCK_EX) == -1)
                err(1, "flock failed");



--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
[hidden email]
_______________________________________________

Community Meeting Calendar:

APAC Schedule -
Every 2nd and 4th Tuesday at 11:30 AM IST
Bridge: https://bluejeans.com/836554017

NA/EMEA Schedule -
Every 1st and 3rd Tuesday at 01:00 PM EDT
Bridge: https://bluejeans.com/486278655

Gluster-devel mailing list
[hidden email]
https://lists.gluster.org/mailman/listinfo/gluster-devel

Reply | Threaded
Open this post in threaded view
|

Re: directory filehandles

amarts


On Sat, Jul 13, 2019 at 7:33 AM Emmanuel Dreyfus <[hidden email]> wrote:
Hello

I have trouble figuring the whole story about how to cope with FUSE
directory filehandles in the NetBSD implementation.

libfuse makes a special use of filehandles exposed to filesystem for
OPENDIR, READDIR, FSYNCDIR, and RELEASEDIR. For that four operations,
the fh is a pointer to a struct fuse_dh, in which the fh field is
exposed to the filesystem. All other filesystem operations pass the fh
as is from kernel to filesystem back and forth.

That means that a fh obtained by OPENDIR should never be passed to
operations others than (READDIR, FSYNCDIR and RELEASEDIR). For instance,
when porting ltfs to NetBSD, I experienced that passing a fh obtained
from OPENDIR to SETATTR would crash.

glusterfs implementation differs from libfuse because it seems the
filesystem is always passed as is: there is nothing like libfuse struct
fuse_dh. It will therefore happily accept fh obtained by OPENDIR for any
operation, something that I do not expect to happen in libfuse based
filesystems.


It would be great to add these comments as part of https://github.com/gluster/glusterfs/issues/153. 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?
 
My real concern is SETLK on directory. Here glusterfs really wants a fh
or it will report an error. The NetBSD implementation passes the fh it
got from OPENDIR, but I expect a libfuse based filesystem to crash in
such a situation. For now I did not find any libfuse-based filesystem
that implements locking, so I could not test that.

Could someone clarify this? What are the FUSE operations that should be
sent to filesystem on that kind of program?

        int fd;

        /* NetBSD  calls FUSE LOOKUP and OPENDIR */
        if ((fd = open("/gfs/tmp", O_RDONLY, 0)) == -1)
                err(1, "open failed");

        /* NetBSD calls FUSE SETLKW */
        if (flock(fd, LOCK_EX) == -1)
                err(1, "flock failed");


Csaba, Raghavendra, Any suggestions here?

-Amar
 


--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
[hidden email]
_______________________________________________

Community Meeting Calendar:

APAC Schedule -
Every 2nd and 4th Tuesday at 11:30 AM IST
Bridge: https://bluejeans.com/836554017

NA/EMEA Schedule -
Every 1st and 3rd Tuesday at 01:00 PM EDT
Bridge: https://bluejeans.com/486278655

Gluster-devel mailing list
[hidden email]
https://lists.gluster.org/mailman/listinfo/gluster-devel


_______________________________________________

Community Meeting Calendar:

APAC Schedule -
Every 2nd and 4th Tuesday at 11:30 AM IST
Bridge: https://bluejeans.com/836554017

NA/EMEA Schedule -
Every 1st and 3rd Tuesday at 01:00 PM EDT
Bridge: https://bluejeans.com/486278655

Gluster-devel mailing list
[hidden email]
https://lists.gluster.org/mailman/listinfo/gluster-devel