On 13/03/2012 18:56, g...@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
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to