Date: Wed, 26 Sep 2012 13:02:54 +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>, freebsd-current@freebsd.org Subject: Re: MPSAFE VFS -- List of upcoming actions Message-ID: <5062E0DE.70805@omnilan.de> In-Reply-To: <5061F6E9.6030104@omnilan.de> 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> <5061F6E9.6030104@omnilan.de>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig26067994D3CAF391E3655218 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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@freebsd.org> wro= te: >>> On Fri, Jul 13, 2012 at 12:18 AM, Attilio Rao <attilio@freebsd.org> w= rote: >>>> 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 pla= n: >>>>>> 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 supp= ort >>>>> 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, a= nd >>>>> 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 rea= l >>>>> 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 i= n >>>> 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 ha= ve >>>> 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 l= ot >>>> 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 fi= nd >>>> 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) an= d >>> 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= =2E >>> 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 orde= r >>> to get fuse, please compile a kernel from this branch with FUSE optio= n >>> or simply build and load fuse module. >>> Alternatively, a kernel patch that should work with HEAD@240684 is he= re: >>> 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.h= tml >>> >>> 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 2407= 52: >> 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? cvs= web provided an esay click if I remember correctly. Thanks, -Harry --------------enig26067994D3CAF391E3655218 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) iEYEARECAAYFAlBi4OMACgkQLDqVQ9VXb8jdSQCbBH3R3wQwRWu0M9XR9PxILRPt oKQAoMGB5IVIx7Ukuk/DSP8vXwp/W29B =sgvs -----END PGP SIGNATURE----- --------------enig26067994D3CAF391E3655218--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5062E0DE.70805>