Port fuse from FreeBSD

[Matthew Dillon]

I think it would be a good project.  Definitely some significant porting
work on the kernel side because our namespace VOP API is quite different,
but the tmpfs code makes for great reference material and I don't think you
would have too much trouble getting it working.  The FUSE API is also
fairly stable I think, so unlike WIFI, a FUSE port can be a one-off.

Some differences between FreeBSD and DragonFly:

* DragonFly has VOP_NRESOLVE to resolve a namespace lookup, and does not
have VOP_LOOKUP.  DragonFly also has numerous other VOP_N*() functions
(e.g. VOP_NRENAME(), VOP_NLINK(), etc).  These functions are similar to
related FreeBSD VOPs but they use the DragonFly mandatory namecache
infrastructure.  Use tmpfs as a reference.  The main thing to get right
with the namespace calls is to be sure to make all the correct cache_*()
calls to keep the namecache in proper synchronization with the filesystem.

* There are probably some minor differences in locking requirements.  Again
using tmpfs as reference material will help a lot.

* In DragonFly, using the buffer cache is mandatory (otherwise mmap() will
not work properly).  tmpfs may not be the best reference here because tmpfs
has some complexity in this regard due to the fact that its data is
actually backed by the buffer cache and VM system and it is not just using
it as a cache.

* VOP_SETATTR and VOP_WRITE are the most complex VOPs.  File truncations
and extensions (including write-appends) require appropriate API calls to
nvtruncbuf() and nvextendbuf().  tmpfs is a good reference for this.
VOP_READ and VOP_WRITE must use the buffer cache, so the actual read and
write operations must be implemented in the buffer cache flushing code
which will be via VOP_STRATEGY.  UFS is probably a good reference for this
if TMPFS is too confusing.  But start with TMPFS.

* When you are first trying to get it to mount, the most important VFS op
to get right, other than VFS_MOUNT, is VFS_ROOT.

* Don't worry about being able to NFS-export a fuse filesystem until the
whole thing is basically working.  This simplifies the VFS ops enormously
because you don't have to support vfs_fhtovp() or vfs_vptofh().

-Matt

On Fri, Sep 16, 2016 at 3:17 AM, Tomohiro Kusumi <kusumi.tomohiro at gmail.com>
wrote:

> Thanks, I'll eventually need you or marino's help on dports side once
> sys/vfs/fuse part starts to work.
>
>
> 2016-09-16 1:01 GMT-04:00 Rimvydas Jasinskas <rimvydasjas at gmail.com>:
> > I'm in, let me know what parts you need in dports.
> >
> >
> >
> > On Fri, Sep 16, 2016 at 12:59 AM, Tomohiro Kusumi
> > <kusumi.tomohiro at gmail.com> wrote:
> >> I'm thinking about porting fuse from FreeBSD. Several benefits by doing
> this.
> >>
> >> 1. There are some good fuse based fs like sshfs, ntfs-3g and maybe
> >> some others I'm not really aware of (like glusterfs if it ever worked
> >> on BSD ?).
> >>
> >> 2. puffs in DragonFly is broken according to other devs/users, and no
> >> one is really going to fix it (which is fine with me too).
> >>
> >> 3. We probably don't need (a broken) puffs if we get (a working) fuse,
> >> given the fact that most userspace filesystems are written for Linux
> >> fuse, but not for NetBSD puffs. NetBSD puffs seems to provide a some
> >> sort of emulation layer for compatibility with fuse, but ours
> >> apparently doesn't because it's broken.
> >>
> >> --
> >> I haven't written any code yet, and won't be for another 2-3 weeks,
> >> but was looking at fuse (a kernel subsystem in FreeBSD and Linux
> >> kernel), libfuse (userspace portion of fuse) and some specific
> >> filesystem implementations such as sshfs.
> >>
> >> The target will be the next DragonFly release which is 4.8. Not sure
> >> if I can make it if we're to release 4.8 within 2016 (which is only 4
> >> months from 4.6), but I should be able to make it otherwise with good
> >> enough stability for the initial release.
> >>
> >> The difficult part is that it's kinda difficult to tell how long it
> >> takes to port fuse, given the concept of the fuse itself. It's easy to
> >> imagine some sort of bugs will be exremely difficult to fix or even
> >> investigate.
> >>
> >> I know DragonFly users want ntfs(3g), but the initial release won't
> >> target ntfs. In theory, having fuse subsystem with good stability
> >> should mean it runs ntfs, but ntfs is probably way too complex to make
> >> it reliably work without bunch of try-and-errors within fuse itself.
> >>
> >> sshfs seems to be a good one for dogfooding the fuse on DragonFly once
> >> it starts to work, because sshfs isn't a toy fs (I think it's quite
> >> popular among Linux users) yet the code size isn't that huge, plus
> >> it's written by the same author as fuse in Linux kernel which
> >> guarantees good code quality.
> >>
> >> If porting a kernel subsystem goes as expected, I'll eventually need
> >> marino@ (or someone who is as good) to help with userspace. One of the
> >> issue with libfuse is that ./configure doesn't recognize DragonFly as
> >> a BSD, probably because our uname doesn't contain "BSD" (see around
> >> line 12000 of ./configure), and tries to compile with Linux specific
> >> code (e.g. mount(2) with 5 arguments instead of four). I may be able
> >> to fix these issues myself, but I doubt I do it in a right way.
> >>
> >> I'm also willing to fix any issues I may encounter on FreeBSD.
> >>
> >> If everything goes as expected, we can get rid of puffs in 4.8.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dragonflybsd.org/pipermail/users/attachments/20160916/7f4cf132/attachment-0002.html>