Date: Fri, 29 Oct 2010 00:18:58 +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> Subject: Re: Fixing and importing the fusefs kernel module - any VFS-savvy takers? Message-ID: <AANLkTi=%2BX7tkoP2N-FUzP%2B5HB77Tjis0cexcgS3-Qh7R@mail.gmail.com> In-Reply-To: <20101028215759.GA6779@tops> References: <AANLkTin0dGcNJMYvXiWC7Diz7jMxAEpXFeeJDK1h3AQO@mail.gmail.com> <20101028141559.GA2291@tops> <AANLkTik7P6GH%2B30sJj1_2yJ%2BtWUD5AbAF5B8E9UNgc5S@mail.gmail.com> <20101028215759.GA6779@tops>
next in thread | previous in thread | raw e-mail | index | archive | help
On 28 October 2010 23:57, Gleb Kurtsou <gleb.kurtsou@gmail.com> wrote: > On (28/10/2010 22:24), Ivan Voras wrote: >> 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)? > > These are sshfs problems, and the real problem is that user level This is good news, since userland is easier to fix. > filesystems are of much lower quality than kernel level. Writing good I wouldn't be that harsh - surely it's just a matter of general code quality whether in userland or kernel; there are a lot more userland file systems because the barrier to entry is lower. > 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. I mostly agree - but as such it is not an argument for or against either puffs or fusefs. > 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? Here's a random sample of user comments and activity indicators I've googled in a few minutes: http://www.gluster.org/gluster-users/ http://www.persistentfs.com/#comments http://code.google.com/p/encfs/updates/list http://sourceforge.net/apps/trac/gfarm/report/1 These are the type of file systems which interest me, there are certainly others.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTi=%2BX7tkoP2N-FUzP%2B5HB77Tjis0cexcgS3-Qh7R>