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

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. :)