Fixing and importing the fusefs kernel module - any VFS-savvy
ivoras at freebsd.org
Thu Oct 28 22:19:42 UTC 2010
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:
These are the type of file systems which interest me, there are
More information about the freebsd-current