Re: MPSAFE VFS -- List of upcoming actions

On Wed, Oct 10, 2012 at 6:15 AM, Kevin Oberman <kob6558_at_gmail.com> wrote:
> 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?

Sorry, forgot to reply about this and it is due: differently from
fuse4bsd version, this one doesn't do device cloning but uses
devfs*cdevpriv() infrastructure. So effectively different
filedescriptors are handled internally. This is why it requires
further changes to the mount_fusefs(8) (because the vfs_mount
operation also need further knowledge on the per-filedescriptor handle
and it cannot acquire it easilly because it is not a devfs operation).

Thanks,
Attilio


-- 
Peace can only be achieved by understanding - A. Einstein