From owner-freebsd-fs@FreeBSD.ORG Tue Mar 13 22:41:12 2012 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BBCBB106566B; Tue, 13 Mar 2012 22:41:12 +0000 (UTC) (envelope-from gperez@entel.upc.edu) Received: from dash.upc.es (dash.upc.es [147.83.2.50]) by mx1.freebsd.org (Postfix) with ESMTP id 3B2908FC08; Tue, 13 Mar 2012 22:41:11 +0000 (UTC) Received: from ackerman2.upc.es (ackerman2.upc.es [147.83.2.244]) by dash.upc.es (8.14.1/8.13.1) with ESMTP id q2DMf3sP013249 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 13 Mar 2012 23:41:03 +0100 Received: from portgus.lan (170.Red-83-44-99.dynamicIP.rima-tde.net [83.44.99.170]) (authenticated bits=0) by ackerman2.upc.es (8.14.4/8.14.4) with ESMTP id q2DMf0uE024989 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 13 Mar 2012 23:41:02 +0100 Message-ID: <4F5FCCD7.7070609@entel.upc.edu> Date: Tue, 13 Mar 2012 23:40:23 +0100 From: =?UTF-8?B?R3VzdGF1IFDDqXJleg==?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.2) Gecko/20120226 Thunderbird/10.0.2 MIME-Version: 1.0 To: gnn@freebsd.org References: <4F5C81BA.1050001@entel.upc.edu> <86ehswtmek.wl%gnn@neville-neil.com> In-Reply-To: <86ehswtmek.wl%gnn@neville-neil.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.70 on 147.83.2.244 X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (dash.upc.es [147.83.2.50]); Tue, 13 Mar 2012 23:41:03 +0100 (CET) Cc: FreeBSD current , fs@freebsd.org Subject: Re: RFC: FUSE kernel module for the kernel... 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: Tue, 13 Mar 2012 22:41:12 -0000 On 13/03/2012 18:56, gnn@freebsd.org wrote: > At Sun, 11 Mar 2012 11:43:06 +0100, > Gustau Pérez wrote: >> On 08/03/2012 22:20, George Neville-Neil wrote: >>> Howdy, >>> >>> I've taken the GSoC work done with the FUSE kernel module, and created a patch against HEAD >>> which I have now subjected to testing using tools/regression/fsx. >>> >>> The patch is here: http://people.freebsd.org/~gnn/head-fuse-1.diff >>> >>> I would like to commit this patch in the next few days, so, please, if you care >>> about this take a look and get back to me. >>> >>> Thanks, >>> George >> Hi, >> >> I'm running HEAD r232383 (as of 2 March) + head-fuse-2.diff in AMD64. >> >> I've been able to use some fuse fs. I run fsx for a while without >> problems with some of them (ext4fuse is readonly). Then ones working were: >> >> sshfs >> ntfs-3g >> ext4fuse >> >> others like: >> >> truecrypt >> gvfs (gnome fuse daemon) >> >> do fail. I tried fsx with gvfs, that's what I got: >> >> [gus@portgus ~]$ /root/deviant2/tools/regression/fsx/fsx >> .gvfs/multimedia\ a\ harkserver/prova >> no extend on truncate! not posix! >> >> They (truecrypt and gvfs) fail when doing setattr/getattr syscalls. >> truecrypt complains about not being able to find the recently created >> encrypted volume (a simple one like $HOME/Desktop/prova). >> >> With gvfs, the nautilus (or the application trying to use the file) >> tries to setattr the file causing gvfs to get an I/O. It happens with >> nearly all kind of files opened with gvfs, although there are some that >> are useable. With those files useable with gvfs, when the application >> closes them causes gvfs to block somewhere, rendering gvfs unuseable. >> >> Those two filesystems can be very useful in the desktop, I guess >> PCBSD could benefit from them. >> >> I would say there is something blocking in >> fuse_vnop_setattr/fuse_vnop_getattr, but I'm not sure how to debug it. >> >> Thanks for your help. >> > Thanks for the detailed report. I'll look into this in a bit, I'm > traveling for two weeks. > > Best, > George Hi, testing ntfs-3g, after doing a bit large transfer with rsync, I found I couldn't unmount the filesystem. After some tries and before checking that no process was accessing the filesystem I tried to force the unmont. After that the system paniced instantly. I'm running HEAD/AMD64 r232862+head-fuse-2.diff. I have a dump of it, but it would seem that fuse is missing debug symbols (I don't know why), so the backtrace is incomplete. I compiled fuse just by doing make on $SRCDIR/sys/modules/fuse. I'll try to reproduce the panic and figure out what happens. Any help would be also appreciated on this other issue. Gustau