From owner-freebsd-fs@FreeBSD.ORG Thu Oct 28 20:25:20 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 354351065679; Thu, 28 Oct 2010 20:25:20 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id C4DF28FC20; Thu, 28 Oct 2010 20:25:19 +0000 (UTC) Received: by qyk2 with SMTP id 2so1285442qyk.13 for ; Thu, 28 Oct 2010 13:25:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=Bzkf3ARGBw6BQeK6ofKhtnm5vlXG+LEv8brH8ak7QZc=; b=nYol1W4pmK+8yLuaINDoiNVaVPK7KebeiHYOdenkO7B71CMviIBT1nuFWyrPmucj3P eHd0NgH5g61f761NJ3R1Flo7l55BHBexyn9IQ5R9szGlpqSjYdBXWBS0txOqkji+xoI5 k/+0V/TzPSvn2w1vSxNWDTXO117+/jhfBZr6Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=SpgY+3qJ3xDvqT1VwbUWwUGPXmeAriGUK4UFZT7aO+SYp9Jlbytsy+ljkjSqcacCbb CZfUrOv7nQYbPEqUYSKzBNhCUZzKYJjTgdWFYIcUHNPlpKQulkaSESaAbjUNbZ4UTsH1 +SmNIfLFcZiWslETi9eQa1VG1Ogj3fhWhhQY8= Received: by 10.224.75.134 with SMTP id y6mr3971718qaj.265.1288297518892; Thu, 28 Oct 2010 13:25:18 -0700 (PDT) MIME-Version: 1.0 Sender: ivoras@gmail.com Received: by 10.229.80.5 with HTTP; Thu, 28 Oct 2010 13:24:37 -0700 (PDT) In-Reply-To: <20101028141559.GA2291@tops> References: <20101028141559.GA2291@tops> From: Ivan Voras Date: Thu, 28 Oct 2010 22:24:37 +0200 X-Google-Sender-Auth: KSDnvwdJ0oSoXf9MJl0fnspCh9M Message-ID: To: Gleb Kurtsou Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 20:25:20 -0000 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=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. :)