Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 25 Sep 2012 20:24:41 +0200
From:      Harald Schmalzbauer <h.schmalzbauer@omnilan.de>
To:        attilio@freebsd.org
Cc:        Peter Holm <pho@freebsd.org>, bdrewery@freebsd.org, FreeBSD FS <freebsd-fs@freebsd.org>, George Neville-Neil <gnn@freebsd.org>, freebsd-current@freebsd.org, =?UTF-8?B?R3VzdGF1IFDDqXJleg==?= <gperez@entel.upc.edu>
Subject:   Re: MPSAFE VFS -- List of upcoming actions
Message-ID:  <5061F6E9.6030104@omnilan.de>
In-Reply-To: <CAJ-FndAisKoCwLkvXpmW=XhXDRH8me8fMjwrfBuWVqfoA95rmQ@mail.gmail.com>
References:  <CAJ-FndCQ0YEo9_6x3g-12XEs8QmtyecwkLBX9z_sptnOUNTHrw@mail.gmail.com>	<20120829060158.GA38721@x2.osted.lan>	<CAJ-FndAaFv2o05MZZceT8Qr4mhPxuzrnmOZ30c3gy8=pnjjZvw@mail.gmail.com>	<20120831052003.GA91340@x2.osted.lan>	<CAJ-FndAaxQA8NYCFSN629XXi9zMVNyu2TuHjZLvmn3jhzRJb4w@mail.gmail.com>	<CAJ-FndDdDVuwc=NgDeG7XiWW59-%2BLs5wc2GBqbjLOLDUdUb9SA@mail.gmail.com>	<20120905201531.GA54452@x2.osted.lan>	<CAJ-FndCHSroZFfVgHAW8SUVZhDSaX9qix=aZnHVC_BN_fW6sgg@mail.gmail.com>	<CAJ-FndDr5WmeKXCwSCucQ4w3hPHRBuu36YH1xiW_wKXOkKEdZg@mail.gmail.com>	<CAJ-FndCvc%2BphY_g4CeGfzsj017roxs_C5adjuLuszpEPWO2%2B1g@mail.gmail.com>	<20120917140055.GA9037@x2.osted.lan>	<CAJ-FndAP9Ua6tRcbrfYY1%2B56O-YbJvmyaUco9K42-0hmchKD6g@mail.gmail.com> <CAJ-FndAisKoCwLkvXpmW=XhXDRH8me8fMjwrfBuWVqfoA95rmQ@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig5956BD299507D7C8FB9E48CE
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

 schrieb Attilio Rao am 21.09.2012 02:22 (localtime):
> On Wed, Sep 19, 2012 at 3:48 AM, Attilio Rao <attilio@freebsd.org> wrot=
e:
>> On Fri, Jul 13, 2012 at 12:18 AM, Attilio Rao <attilio@freebsd.org> wr=
ote:
>>> 2012/7/4 Attilio Rao <attilio@freebsd.org>:
>>>> 2012/6/29 Attilio Rao <attilio@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 suppo=
rt
>>>> 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, an=
d
>>>> 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 i=
s
>>>> 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 hav=
e
>>> 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 lo=
t
>>> 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 fin=
d
>>> 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@240684 is her=
e:
>> 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.ht=
ml
>>
>> 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 24075=
2:
> 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

Thanks for any hint.

-Harry


--------------enig5956BD299507D7C8FB9E48CE
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (FreeBSD)

iEYEARECAAYFAlBh9u4ACgkQLDqVQ9VXb8gpAwCfb5VoWs1KCpoaAowEGEmXaYyo
FGAAnRAqlgLO5GN46sxm63FoIcinBDX2
=ZOwb
-----END PGP SIGNATURE-----

--------------enig5956BD299507D7C8FB9E48CE--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5061F6E9.6030104>