Date: Thu, 28 Oct 2010 17:15:59 +0300 From: Gleb Kurtsou <gleb.kurtsou@gmail.com> To: Ivan Voras <ivoras@freebsd.org> Cc: freebsd-fs <freebsd-fs@freebsd.org>, FreeBSD-Current <freebsd-current@freebsd.org>, kris@pcbsd.org Subject: Re: Fixing and importing the fusefs kernel module - any VFS-savvy takers? Message-ID: <20101028141559.GA2291@tops> In-Reply-To: <AANLkTin0dGcNJMYvXiWC7Diz7jMxAEpXFeeJDK1h3AQO@mail.gmail.com> References: <AANLkTin0dGcNJMYvXiWC7Diz7jMxAEpXFeeJDK1h3AQO@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On (28/10/2010 13:49), Ivan Voras wrote: > Hello, > > After a discussion in arch@, 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 @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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20101028141559.GA2291>