RFC: FUSE kernel module for the kernel...
gperez at entel.upc.edu
Sun Mar 11 11:58:08 UTC 2012
On 08/03/2012 22:20, George Neville-Neil wrote:
> 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.
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:
gvfs (gnome fuse daemon)
do fail. I tried fsx with gvfs, that's what I got:
[gus at 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.
More information about the freebsd-current