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

From: Ivan Voras <ivoras_at_freebsd.org>
Date: Fri, 29 Oct 2010 00:18:58 +0200
On 28 October 2010 23:57, Gleb Kurtsou <gleb.kurtsou_at_gmail.com> wrote:
> 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

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.
Received on Thu Oct 28 2010 - 20:19:42 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:08 UTC