Date: Thu, 28 Oct 2010 22:24:37 +0200 From: Ivan Voras <ivoras@freebsd.org> To: Gleb Kurtsou <gleb.kurtsou@gmail.com> 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: <AANLkTik7P6GH%2B30sJj1_2yJ%2BtWUD5AbAF5B8E9UNgc5S@mail.gmail.com> In-Reply-To: <20101028141559.GA2291@tops> References: <AANLkTin0dGcNJMYvXiWC7Diz7jMxAEpXFeeJDK1h3AQO@mail.gmail.com> <20101028141559.GA2291@tops>
next in thread | previous in thread | raw e-mail | index | archive | help
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=3D0, the same way > st_ino=3D0. To make it actually work (dirent's with d_file=3D0 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). =C2=A0What I don't like about puffs is that is basically ignore= s > 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. :)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTik7P6GH%2B30sJj1_2yJ%2BtWUD5AbAF5B8E9UNgc5S>