Re: MPSAFE VFS -- List of upcoming actions

From: Kevin Oberman <kob6558_at_gmail.com>
Date: Tue, 9 Oct 2012 22:15:35 -0700
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.com
Received 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