Re: Fixing and importing the fusefs kernel module - any VFS-savvy takers?

On (28/10/2010 13:49), Ivan Voras wrote:
> Hello,
> 
> After a discussion in arch_at_, it looks like there are many developers
> interested in having fusefs in the tree but no VFS experts with the
> time to fix the remaining bugs and basically make it stable enough to
> commit to the base tree.
> 
> Fusefs is the Linux-developed userland filesystem interface which is
> fairly popular in the wild, especially with the "sshfs" module which
> allows mounting of generic ssh/sftp directories in a very easy way.
> Among other filesystems developed for fuse there are some cluster file
> systems, some crypto file systems and helper file systems used by
> Gnome and such environments. The initial FreeBSD reimplementation of
> the kernel module (the userland utlities and libraries don't require
> complicated porting) was was developed in one of the very early Google
> Summer of Code projects (2005) and is now in a bit unusual situation:
> 
> 1) it *is* popular, as reports about its breakage arrive pretty soon
> after it breaks (i.e. due to mainline kernel changes)
> 
> 2) it is currently available as a port but it is practically
> unmaintained. The source code archive is from 2008 and the port
> contains a dozen patches to be applied to it to make it work on recent
> systems
> 
> 3) it is also not exactly rock stable, though this has improved with
> the above patches;
> 
> Currently, with sshfs, it is good enough to:
> 
>     - survive blogbench runs
>     - survive fsx runs with arguments "-W -R -L", i.e. no mmaped
> operations, no file size altering / truncate operations
> 
> There have been claims it also corrupts kernel memory.
> 
> Basically, this is a call for help in working on fusefs. There are
> several developers and users willing to do testing and such but no
> available developers with their hands in the guts of VFS to squash the
> buried bugs. Fusefs might be especially relevant to desktop users and
> as such to PC-BSD developers, so I'm cc-ing Kris in case he has a
> comment.
> 
> Is anyone interested?

Hi Ivan,

I didn't reply to thread on _at_current as it seemed to me that decision
was to keep it as it is until someone steps in to maintain it.

I'd agree that "sshfs" is most wanted feature, but fuse_sshfs
implementation is broken at best. It doesn't even have notion on inode
numbers. It returns all directory entries with d_file=0, the same way
st_ino=0. To make it actually work (dirent's with d_file=0 considered
empty placeholders by FreeBSD VFS and libc) librefuse fills it with
arbitrary numbers. To make long story short stuff like 'cd ..' works for
you only because your sh and/or filemanager keeps full path on its own.
Lots of other things using VOP_VPTOCNP are also broken. In this
particular case puffs_sshfs looks much more promising, although it's
explicitly marked as incomplete and buggy. The same applies to vast
majority of fuse filesystems. Ignoring it is probably the easiest way to
solve the problem, but I'd expect future userlevel filesystem
implementation to comply to our VFS.

Absence of mmap support is a real show stopper. It's also broken in
puffs, and doesn't pass fsx tests. (I've once started implementing it
but lost interest in userlevel filesystems after digging deeper into
it.) On the other hand adding it to fuse shouldn't be very hard, it's
just a question of free time.

To sum it up. My personal opinion is that we'd better go with
puffs-style approach. Implement userspace-kernel protocol that is as
much close to our VFS as possible, and implement proper wrapper like
librefuse (which is ok, but looks more like sketch than ready to use
library).  What I don't like about puffs is that is basically ignores
locking serializing request from kernel.

I'd suggest we ask a person with skills in network filesystems: locking,
caching and all related issues, and improve existing puffs
infrastructure accordingly (that includes inode numbers problem I've
mentioned before). NFS4 might have interesting ideas. Probably Rick
Macklem could express his opinion on this regard.

Besides as far as I know OpenAFS has user-kernel interface and
implements filesystem at userspace. Sun or Apple have reimplemented fuse
in their own, although initial version was based on FreeBSD fuse port.
It might be worth checking before moving any further with fuse.

> 
> References:
> 
> http://permalink.gmane.org/gmane.os.freebsd.architechture/13623
> http://fuse.sourceforge.net/
> http://fuse4bsd.creo.hu/
> http://www.freebsd.org/cgi/cvsweb.cgi/ports/sysutils/fusefs-kmod/
> http://old.nabble.com/forum/Search.jtp?forum=6572&local=y&query=fusefs
> http://old.nabble.com/forum/Search.jtp?forum=6610&local=y&query=fusefs