Re: MPSAFE VFS -- List of upcoming actions

 schrieb Harald Schmalzbauer am 25.09.2012 20:24 (localtime):
>  schrieb Attilio Rao am 21.09.2012 02:22 (localtime):
>> On Wed, Sep 19, 2012 at 3:48 AM, Attilio Rao <attilio_at_freebsd.org> wrote:
>>> On Fri, Jul 13, 2012 at 12:18 AM, Attilio Rao <attilio_at_freebsd.org> wrote:
>>>> 2012/7/4 Attilio Rao <attilio_at_freebsd.org>:
>>>>> 2012/6/29 Attilio Rao <attilio_at_freebsd.org>:
>>>>>> As already published several times, according to the following plan:
>>>>>> http://wiki.freebsd.org/NONMPSAFE_DEORBIT_VFS
>>>>>>
>>>>> I still haven't heard from Vivien or Edward, anyway as NTFS is
>>>>> basically only used RO these days (also the mount_ntfs code just
>>>>> permits RO mounting) I stripped all the uncomplete/bogus write support
>>>>> with the following patch:
>>>>> http://www.freebsd.org/~attilio/ntfs_remove_write.patch
>>>>>
>>>>> This is an attempt to make the code smaller and possibly just focus on
>>>>> the locking that really matter (as read-only filesystem).
>>>>> On some points of the patch I'm a bit less sure as we could easily
>>>>> take into account also write for things like vaccess() arguments, and
>>>>> make easier to re-add correct write support at some point in the
>>>>> future, but still force RO, even if the approach used in the patch is
>>>>> more correct IMHO.
>>>>> As an added bonus this patch cleans some dirty code in the mount
>>>>> operation and fixes a bug as vfs_mountedfrom() is called before real
>>>>> mounting is completed and can still fail.
>>>> A quick update on this.
>>>> It looks like NTFS won't be completed for this GSoC thus I seriously
>>>> need to find an alternative to not loose the NTFS support entirely.
>>>>
>>>> I tried to look into the NTFS implementation right now and it is
>>>> really a poor support. As Peter has also verified, it can deadlock in
>>>> no-time, it compeltely violates VFS rules, etc. IMHO it deserves a
>>>> complete rewrite if we would still support in-kernel NTFS. I also
>>>> tried to look at the NetBSD implementation. Their code is someway
>>>> similar to our, but they used very complicated (and very dirty) code
>>>> to do the locking. Even if I don't know well enough NetBSD VFS, I have
>>>> the impression not all the races are correctly handled. Definitively,
>>>> not something I would like to port.
>>>>
>>>> Considering all that the only viable option would be meaning an
>>>> userland filesystem implementation. My preferred choice would be to
>>>> import PUFFS and librefuse on top of it but honestly it requires a lot
>>>> of time to be completed, time which I don't currently have as in 2
>>>> months Giant must be gone by the VFS.
>>>>
>>>> I then decided to switch to gnn's rewamp of FUSE patches. You can find
>>>> his initial e-mail here:
>>>> http://lists.freebsd.org/pipermail/freebsd-fs/2012-March/013876.html
>>>>
>>>> I've precisely got the second version of George's patch and created
>>>> this dolphin branch:
>>>> svn://svn.freebsd.org/base/projects/fuse
>>>>
>>>> I'm fixing low hanging fruit for the moment (see r238411 for example)
>>>> and I still have to make a throughful review.
>>>> However my idea is to commit the support once:
>>>> - ntfs-3g is well stress-tested and proves to be bug-free
>>>> - there is no major/big technical issue pending after the reviews
>>> In the last weeks Peter, Florian, Gustau and I have been working in
>>> stabilizing fuse support. In the specific, Peter has worked hard on
>>> producing several utilities to nit stress-test fuse and in particular
>>> ntfs, Florian has improved fuse related ports (as explained later) and
>>> Gustau has done sparse testing. I feel moderately satisfied by the
>>> level of stability of fuse now to propose to wider usage, in
>>> particular given the huge amount of complaints I'm hearing around
>>> about occasional fuse users.
>>>
>>> The final target of the project is to completely import into base the
>>> content of fusefs-kmod starting from earlier posted patches by George.
>>> So far, we took care only of importing in the fuse branch the kernel
>>> part, so that fusefs-kmod userland part is still needed to be
>>> installed from ports, but I was studying the mount_fusefs licensing
>>> before to process with the import for the userland bits of it.
>>>
>>> The fixing has been happening here:
>>> svn://svn.freebsd.org/base/projects/fuse/
>>>
>>> which is essentially an HEAD branch + fuse kernel components. In order
>>> to get fuse, please compile a kernel from this branch with FUSE option
>>> or simply build and load fuse module.
>>> Alternatively, a kernel patch that should work with HEAD_at_240684 is here:
>>> http://www.freebsd.org/~attilio/fuse_import/fuse_240684.patch
>>>
>>> I guess the patch can easilly apply to all FreeBSD branches, really,
>>> but it is not tested to anything else different then -CURRENT.
>>>
>>> As said you still need currently to build fusefs-kmod port. However
>>> you need these further patches, to be put in the fusefs-kmod/files/
>>> directory::
>>> http://www.freebsd.org/~attilio/fuse_import/patch-Makefile
>>> http://www.freebsd.org/~attilio/fuse_import/patch-mount_fusefs__mount_fusefs2.c
>>>
>>> They both disable the old kernel building/linking and import new
>>> functionality to let the new kernel support work well in presence of
>>> many consumers.
>>>
>>> In addition to fusefs-kmod, Bryan and Florian have also updated
>>> fusefs-lib and fusefs-ntfs ports. For instance, please refer to this
>>> e-mail:
>>> http://lists.freebsd.org/pipermail/freebsd-ports/2012-August/077950.html
>>>
>>> Even if this work is someway independent by the fusefs-kmod import, I
>>> warmly suggest to all of you to use their patches (and this what we
>>> have been testing so far too.
>> So, after Bryan and Florian ports update, I've also committed userland
>> part of fusefs-kmod and now the project branch fully mirrors
>> functionality of fusefs-kmod. The code in projects/fuse, infact, will
>> also install mount_fusefs as part of the fuse support.
>>
>> You can use the branch directly or this patch against -CURRENT at 240752:
>> http://www.freebsd.org/~attilio/fuse_import/fuse_240752.patch
> Hello,
>
> first, many thanks for your effort bringing fusefs support into base
> with decent stability!!!
> I tried to compile RELENG_9_1 with your patch, but failed figuring out
> why compiling world stops with this error:
>
> src/sbin/mount_fusefs/mount_fusefs.c:319: error: void value not ignored
> as it ought to be
> *** [mount_fusefs.o] Error code 1

Reason is sbin/mount/getmntopts.c, where checkpath() is void, which
changed to int in r230226 8 monthas ago in head.

Log:
   Change checkpath() to not exit on error. This is a prerequisite for
   fixing the mount(8) "failok" option.

Some questions: Is this planned to be mfc'd and if so, how can one know?
And another svn-dummie question: How can I get the committ as a diff? cvsweb provided an esay click if I remember correctly.

Thanks,

-Harry