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

> From: Ivan Voras <ivoras_at_freebsd.org>
> Date: Thu, 28 Oct 2010 22:24:37 +0200
> Sender: owner-freebsd-current_at_freebsd.org
> 
> On 28 October 2010 16:15, Gleb Kurtsou <gleb.kurtsou_at_gmail.com> wrote:
> 
> > 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.
> 
> For these fuse-sshfs problems, how many are the problem of sshfs (the
> userland code), the FUSE API (because it's designed for Linux) and the
> fuse4bsd kernel module (because it's unfinished and buggy)?
> 
> > 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'm trying to avoid dispersal of effort. Basically, I won't be
> convinced to support puffs until someone who knows (possibly you if
> you are up to it) demonstrates that the refuse API is stable enough
> and practically 100% compatible with FUSE - some of their file systems
> look fit for serious use and "99%" isn't very much when talking about
> OS stability.
> 
> On the other hand, if a developer suddenly appears and says "I will
> make puffs+refuse work" I will support him completely and I will stop
> crusading for fuse because having puffs is better than nothing. :)

While support for sshfs may be important, I find ntfs-3g more important
and both of these pale when compared to the gvfs-fuse-daemon in
Gnome. It's just than I doubt most Gnome users even realize that it's
there. 
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman_at_es.net			Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751