[Gluster-devel] NetBSD FUSE and filehandles

[Csaba Henk]

Hi Manu,

My memories of FUSE internals are a bit rusty, but I try
to give a usable answer.

Your description is essentially correct, but some of it
needs to be addressed more carefully. The Linux kernel's
VFS internally maintains file objects. They are tied to a given
call of open(2). The file handle is an user defined entity and
as such can be unique to open calls or shared between some
 of them (eg. like opens dispatched to the same
backing resource; or in a completely stateless file system
might choose it to be a constant). Anyway, the kernel
will store the file handle identifier along with the file object,
so if you choose them to be unique per open call, it will be
mapped one-to-one to the in-kernel file objects.

However, (pid, fd) won't be one-to-one mapped to the in-kernel
file objects, because process of pid1 might fork a process of pid2,
whereby files inherit, so (pid1, fd) and (pid2, fd) will be associated
with the same file object.

I hope I did not make a mistake in this recollection.

I also have a vague memory that in Linux VFS the file operations
are dispatched to file objects in quite a pure oop manner (which
suggests itself to practices like "storing the file handle identifier
along with the file object"), while in traditional BSD VFS the file
ops just get the vnode (from which modernization efforts departed
to various degree across the recent BSD variants).

Csaba

On Mon, Apr 4, 2016 at 6:43 AM, Emmanuel Dreyfus <manu at netbsd.org> wrote:
> 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 at netbsd.org
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel