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

[Gleb Kurtsou]

On (28/10/2010 22:24), Ivan Voras wrote:
> 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)?
These are sshfs problems, and the real problem is that user level
filesystems are of much lower quality than kernel level. Writing good
filesystems in userspace shouldn't be much easier than writing kernel
one (not counting fancy language of choice and ntfs-3g-like use of
binary drivers). All the kernel restrictions and requirements are still
there nor puffs, nor fuse do black magic for you.

> > 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 - 
No-no, I'm not convincing you to choose puffs. It's too immature. I just
like the approach.

> some of their file systems
> look fit for serious use and "99%" isn't very much when talking about
> OS stability.
That's why I'm so sceptical about fuse, puffs, and entire concept in
general. Is fuse really that stable on linux? Do people use it on
production servers?

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