From owner-freebsd-fs@FreeBSD.ORG Thu Oct 28 21:56:28 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 753941065674; Thu, 28 Oct 2010 21:56:28 +0000 (UTC) (envelope-from oberman@es.net) Received: from mailgw.es.net (mail1.es.net [IPv6:2001:400:201:1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 5D87A8FC16; Thu, 28 Oct 2010 21:56:28 +0000 (UTC) Received: from ptavv.es.net (ptavv.es.net [IPv6:2001:400:910::29]) by mailgw.es.net (8.14.3/8.14.3) with ESMTP id o9SLuRGT005238 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 28 Oct 2010 14:56:28 -0700 Received: from ptavv.es.net (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 83C2E1CC45; Thu, 28 Oct 2010 14:56:27 -0700 (PDT) To: Ivan Voras In-reply-to: Your message of "Thu, 28 Oct 2010 22:24:37 +0200." Date: Thu, 28 Oct 2010 14:56:27 -0700 From: "Kevin Oberman" Message-Id: <20101028215627.83C2E1CC45@ptavv.es.net> Cc: freebsd-fs , FreeBSD-Current , kris@pcbsd.org Subject: Re: Fixing and importing the fusefs kernel module - any VFS-savvy takers? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 21:56:28 -0000 > From: Ivan Voras > Date: Thu, 28 Oct 2010 22:24:37 +0200 > Sender: owner-freebsd-current@freebsd.org > > On 28 October 2010 16:15, Gleb Kurtsou 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