Date: Tue, 13 Mar 2012 23:40:23 +0100 From: =?UTF-8?B?R3VzdGF1IFDDqXJleg==?= <gperez@entel.upc.edu> To: gnn@freebsd.org Cc: FreeBSD current <freebsd-current@freebsd.org>, fs@freebsd.org Subject: Re: RFC: FUSE kernel module for the kernel... Message-ID: <4F5FCCD7.7070609@entel.upc.edu> In-Reply-To: <86ehswtmek.wl%gnn@neville-neil.com> References: <C55C880E-8DA3-42A8-9837-32D4B02FD742@FreeBSD.org> <4F5C81BA.1050001@entel.upc.edu> <86ehswtmek.wl%gnn@neville-neil.com>
index | next in thread | previous in thread | raw e-mail
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. Gustauhelp
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F5FCCD7.7070609>