Hi
Anoop C S asked me about a NetBSD FUSE bug that prevented mandatory
locks to properly work. In order to work on a fix, I need confirmation
about how it works on Linux, which is the reference implementation of
FUSE.
Here is what I understand, please tell me if there is something wrong:
Each time a process opens a file within the FUSE filesystem, the kernel
will call the FUSE open method, and the filesystem shall return a
filehandle. For subsequent operations on the open file descriptor, the
kernel will include the adequate filehandle in the FUSE requests.
The filehandle is tied to the couple (calling process, file descriptor
within calling process). Each time the calling process calls open again
on the same file, a new file handle is returned. This means this creates
two distincts file handles;
fd1 = open("/mnt/foo", O_RDWR);
fd2 = open("/mnt/foo", O_RDWR);
Is all of that correct? If it is, here is the problem I face now: the
NetBSD kernel implements PUFFS, an interface smilar but incompatible
with FUSE that was developped before FUSE became the de-facto standard.
I have being maintaining the PUFFS to FUSE compatibility layer we use to
run Glusterfs on NetBSD.
PUFFS sends userland requests about vnode operations, the userland
filesystems gets references to the vnode, it can also get the calling
process PID, but currently the file descriptor within calling process is
not provided to the userland filesystem.
If my understanding of FUSE filehandle semantics is correct, that means
I will have to modify the PUFFS interface so that operations on open
files get a reference about the file descriptor within calling process,
since this is a requirement to retreive the appropriate filehandle for
FUSE.
Anyone can confirm?
--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu@xxxxxxxxxx
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel
