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>