On Mon, Oct 8, 2012 at 7:57 AM, Attilio Rao <attilio_at_freebsd.org> wrote: > On Fri, Sep 28, 2012 at 4:47 PM, Harald Schmalzbauer > <h.schmalzbauer_at_omnilan.de> wrote: >> schrieb Attilio Rao am 28.09.2012 16:18 (localtime): >>> On Wed, Sep 26, 2012 at 12:02 PM, Harald Schmalzbauer >>> <h.schmalzbauer_at_omnilan.de> wrote: >>>> ... >>> After many people willing to test fuse on STABLE_9, I made this patch >>> that at least compiles there: >>> http://www.freebsd.org/~attilio/fuse_import/fuse_stable9_241030.patch >> >> Thanks a lot! In the meantime I made the original patch compiling. I >> simply looked at the changes which were made around july in the fuse >> project to follow changes in head (checkpath(), vrecycle() and >> vtruncbuf()) and "reverted" them. >> Since I have no idea about the code I modified, I'm happy that you did a >> more qualified patch set :-) >> >>> Of course, I didn't have a chance to test it because I'm also out for >>> vacation right now but please do and report. >> >> Happy holiday!!! If you're by chance arround the Oktoberfest, drop me a >> note, I'll pay you a Maß (or any other drink if you don't like >> „Wiesnbier“) :-) > > I really hoped to make this year, but no luck :/ > >>>> ... >>>> Some questions: Is this planned to be mfc'd and if so, how can one know? >>> In which sense "how can one know?". We usually specify MFC timeouts in >>> the commit message (not sure if this answers your concerns). >> >> Yep, that's what I wanted to know. So if there's no MFC timeout in the >> log, it's not intended to be MFCd ever I guess. >> >> Thanks a lot! >> World/Kernel compiled fine in the meantime, I'll do some sshfs tests. > > Did you do any test in the end? > > Thanks, > Attilio i have done same testing and it clearly is more stable than the old kmod. At least operations that crashed my system now work. I did see one weird anomaly, though. I had several NTFS file system mounted, one a Windows OS. I also had a GELI encrypted UFS file system mounted. They were both mounted and working. I finished with the data disk and tried to unmount it. I got no error, but it remained mounted. I did not actually try to access it. Figured it would umount when I shut down or end up dirty and I'd have to fsck it. The unmount attempt was using nautilus/gnome-mount. This is not the odd part, though. After the attempt to unmount the UFS device, I could no longer access the Window_OS file system. an ls showed the mount point to be d--------- and an attempt to list files in the directory reported that the socket was not found. So it looks like the attempt to unmount one NTFS FS deleted the socket for the other. This make absolutely no sense to me, but you understand the underlying opertations better than I do. Repeated efforts have failed to re-create the problem. I'm baffled. It is possible that there is no relationship between the two odd things happening at about the same time (NTFS volume lost socket and UFS disk won;t unmount, but reports no errors), but neither has happened since. FWIW, I also see that no device numbers are listed for the fuse devices: /dev/fuse 184319948 165594236 18725712 90% /media/Media /dev/fuse 110636028 82934424 27701604 75% /media/Windows7_OS How does the system distinguish between them? -- R. Kevin Oberman, Network Engineer E-mail: kob6558_at_gmail.comReceived on Wed Oct 10 2012 - 03:15:39 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:31 UTC