Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 13 Mar 2012 13:56:35 -0400
From:      gnn@freebsd.org
To:        Gustau =?UTF-8?B?UMOpcmV6?= <gperez@entel.upc.edu>
Cc:        FreeBSD current <freebsd-current@freebsd.org>, fs@freebsd.org
Subject:   Re: RFC: FUSE kernel module for the kernel...
Message-ID:  <86ehswtmek.wl%gnn@neville-neil.com>
In-Reply-To: <4F5C81BA.1050001@entel.upc.edu>
References:  <C55C880E-8DA3-42A8-9837-32D4B02FD742@FreeBSD.org> <4F5C81BA.1050001@entel.upc.edu>

next in thread | previous in thread | raw e-mail | index | archive | help
At Sun, 11 Mar 2012 11:43:06 +0100,
Gustau PĂ©rez wrote:
>=20
> 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
>=20
>     Hi,
>=20
>    I'm running HEAD r232383 (as of 2 March) + head-fuse-2.diff in AMD64.
>=20
>    I've been able to use some fuse fs. I run fsx for a while without=20
> problems with some of them (ext4fuse is readonly). Then ones working were:
>=20
>          sshfs
>          ntfs-3g
>          ext4fuse
>=20
>    others like:
>=20
>          truecrypt
>          gvfs (gnome fuse daemon)
>=20
>    do fail. I tried fsx with gvfs, that's what I got:
>=20
>          [gus@portgus ~]$ /root/deviant2/tools/regression/fsx/fsx=20
> .gvfs/multimedia\ a\ harkserver/prova
>          no extend on truncate! not posix!
>=20
>    They (truecrypt and gvfs) fail when doing setattr/getattr syscalls.=20
> truecrypt complains about not being able to find the recently created=20
> encrypted volume (a simple one like $HOME/Desktop/prova).
>=20
>     With gvfs, the nautilus (or the application trying to use the file)=20
> tries to setattr the file causing gvfs to get an I/O. It happens with=20
> nearly all kind of files opened with gvfs, although there are some that=20
> are useable. With those files useable with gvfs, when the application=20
> closes them causes gvfs to block somewhere, rendering gvfs unuseable.
>=20
>    Those two filesystems can be very useful in the desktop, I guess=20
> PCBSD could benefit from them.
>=20
>    I would say there is something blocking in=20
> fuse_vnop_setattr/fuse_vnop_getattr, but I'm not sure how to debug it.
>=20
>    Thanks for your help.
>=20

Thanks for the detailed report.  I'll look into this in a bit, I'm
traveling for two weeks.

Best,
George



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?86ehswtmek.wl%gnn>