git: sys/vfs/fuse: Fix a ton of stuff and get writes working

[Tomohiro Kusumi]

Thanks for the explanation. I think you're looking at different
aspects of FUSE fh, which could be beyond what I'm seeing.

A few days ago I said FUSE is more or less designed for Linux kernel (
https://lists.dragonflybsd.org/pipermail/commits/2024-March/923204.html
), which you disagreed, but I found a page (by Alan who rewrote
FreeBSD FUSE) that describes more details.

https://github.com/libfuse/libfuse/issues/389
"In fact, the entire concept of a file handle is really a Linuxism.
Other operating systems enforce a distinction between the file layer
and the vnode layer. That's why OSX, FreeBSD, OpenBSD, and Illumos can
almost never guarantee that they're sending the right file handle for
any operation. NetBSD takes a more extreme position; it doesn't allow
multiple concurrent fuse file handles for a single file (which leads
to other problems)."

I think it's a well known fact for anyone who tried to implement FUSE
on BSD variants though. FUSE fh is something supposed to be maintained
1:1 with open-file if any, not 1:1 with vnode or N:1 by sharing
tricks.


2024年3月15日(金) 11:35 Matthew Dillon <dillon at backplane.com>:
>
> Fuse operates with two different types of identifiers.   Inode numbers (which are passive), and file handles (which are active).  Inode numbers are used for most VOP operations (e.g. namespace operations, GETATTR, NRESOLVE, etc), while file handles are used for operations within a file (READ, WRITE, TRUNCATE/EXTEND).
>
> There is no need to maintain more than one active file-handle in-kernel associated with a regular file or directory.   Filesystem FIFOs, devices, and sockets are different, but lets not worry about those for now.
>
> For regular files seek position is included in every I/O operation.  Now there are probably some minor issues with this in VOP_OPEN in terms of foi->flags = OFLAGS(ap->a_mode), whether the first file handle is opened O_RDONLY or O_RDWR, which some FUSE userland frontends might be sensitive to.   O_TRUNC is handled by DragonFly so that isn't an issue.  The ext2fs frontend doesn't seem to care about O_RDONLY vs O_RDWR being passed in... I can open a file for reading in one program and then later open it for writing in another.   But at worst all this means is that we might need to maintain up to two file-handles per fuse_node instead of one.
>
> For regular directories we might need to track seek position... the current FUSE driver code for VOP_READDIR is kinda broken and always supplies an offset of 0 and tries to read the entire directory in one operation, then skips entries based on uio_offset before starting to fill in the data buffer.   i.e. any directories longer than 10 * PAGE_SIZE will break at the moment.
>
> So basically any number of open()s can be concurrent on a FUSE file or directory, but only one file handle actually needs to be maintained. Hence if you look at line 178 of fuse_vnops.c you will see that I conditionalize the open operation such that it only obtains one file handle.
>
> If ucred matters at all (ext2 ignores it as well I believe)... if ucred matters at all, we can just pass root creds in the RPC for everything.
>
> -Matt