From owner-freebsd-fs@FreeBSD.ORG Wed Sep 26 11:03:05 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 293BE1065670; Wed, 26 Sep 2012 11:03:05 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (s1.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 8A7D88FC12; Wed, 26 Sep 2012 11:03:03 +0000 (UTC) Received: from titan.inop.wdn.omnilan.net (titan.inop.wdn.omnilan.net [172.21.3.1]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id q8QB3utb023943 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Sep 2012 13:03:59 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <5062E0DE.70805@omnilan.de> Date: Wed, 26 Sep 2012 13:02:54 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: attilio@freebsd.org References: <20120829060158.GA38721@x2.osted.lan> <20120831052003.GA91340@x2.osted.lan> <20120905201531.GA54452@x2.osted.lan> <20120917140055.GA9037@x2.osted.lan> <5061F6E9.6030104@omnilan.de> In-Reply-To: <5061F6E9.6030104@omnilan.de> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig26067994D3CAF391E3655218" Cc: Peter Holm , bdrewery@freebsd.org, FreeBSD FS , freebsd-current@freebsd.org Subject: Re: MPSAFE VFS -- List of upcoming actions X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 11:03:05 -0000 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 wro= te: >>> On Fri, Jul 13, 2012 at 12:18 AM, Attilio Rao w= rote: >>>> 2012/7/4 Attilio Rao : >>>>> 2012/6/29 Attilio Rao : >>>>>> 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--