Date: Thu, 28 Oct 2010 14:56:27 -0700 From: "Kevin Oberman" <oberman@es.net> 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: <20101028215627.83C2E1CC45@ptavv.es.net> In-Reply-To: Your message of "Thu, 28 Oct 2010 22:24:37 %2B0200." <AANLkTik7P6GH%2B30sJj1_2yJ%2BtWUD5AbAF5B8E9UNgc5S@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> From: Ivan Voras <ivoras@freebsd.org> > Date: Thu, 28 Oct 2010 22:24:37 +0200 > Sender: owner-freebsd-current@freebsd.org > > On 28 October 2010 16:15, Gleb Kurtsou <gleb.kurtsou@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@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20101028215627.83C2E1CC45>