From owner-freebsd-current@FreeBSD.ORG Wed Sep 19 07:30:14 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1CFF1106564A; Wed, 19 Sep 2012 07:30:14 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 755DD8FC0C; Wed, 19 Sep 2012 07:30:12 +0000 (UTC) Received: by lahe6 with SMTP id e6so410484lah.13 for ; Wed, 19 Sep 2012 00:30:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=/L2gqn9cpJ29eGUEFoYpM+7cUjSo/qtgHi48XJNYoIw=; b=ybHEeBhUGiL9VFpmOGdxlL5HLbf0nTQbDflRirEJJ+2ZdB29FRS2YgKYUDW2m1PGvX L4E+jWQ0cn19DdrXzwu0wLW3bXM+KbCP0XNYIHWFDFtMNd1GrvemWeptSs86B0MrObzG JnWzfi/1VyNx7Hkm5e7v3SCpSa5g2iNfPCW86+7E4Dkktitt/FyJDcSqQiD3YD/OSr6w hRlnVs+rAZs38RZ7ZCR3tsM5PrI6UZtOMTVcCBOJ8ao55io8/ecujpb8aQ1zQQtG4SYt nN4q1Kr/G6EBWgaDuwufEHC99VFaRq4zCZtsoDODfXSQxNI2lVM2EV70PYef+BvcvpfP fcDg== MIME-Version: 1.0 Received: by 10.152.131.68 with SMTP id ok4mr1888249lab.47.1348039811094; Wed, 19 Sep 2012 00:30:11 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.112.102.39 with HTTP; Wed, 19 Sep 2012 00:30:11 -0700 (PDT) In-Reply-To: References: <20120829060158.GA38721@x2.osted.lan> <20120831052003.GA91340@x2.osted.lan> <20120905201531.GA54452@x2.osted.lan> <20120917140055.GA9037@x2.osted.lan> Date: Wed, 19 Sep 2012 08:30:11 +0100 X-Google-Sender-Auth: E7omFsgrPjQO55RBiG5X8WqrrcY Message-ID: From: Attilio Rao To: Kevin Oberman Content-Type: text/plain; charset=UTF-8 Cc: Peter Holm , bdrewery@freebsd.org, FreeBSD FS , George Neville-Neil , freebsd-current@freebsd.org, =?UTF-8?Q?Gustau_P=C3=A9rez?= Subject: Re: MPSAFE VFS -- List of upcoming actions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: attilio@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 07:30:14 -0000 On Wed, Sep 19, 2012 at 4:47 AM, Kevin Oberman wrote: > On Tue, Sep 18, 2012 at 7:48 PM, Attilio Rao wrote: >> On Fri, Jul 13, 2012 at 12:18 AM, Attilio Rao wrote: >>> 2012/7/4 Attilio Rao : >>>> 2012/6/29 Attilio Rao : >>>>> 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@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). >> >> At this point what I'm looking for are reviews and further testing. >> I would like to spend some words on what you should expect from this work: >> *Fuse is far from being perfect*. >> I cannot stress this enough. Peter stress-tests could break also Fuse >> on Linux generally and by Fuse authors admissions the modules can >> never guarantee to be completely starvation-free. However, they tend >> to be designed in a way that sleeps can be at least interrupted >> easily, making at least easy to recover from deadlocks. This is mostly >> retained also in FreeBSD, for what I can tell. Also, sometimes fuse >> seems to leave a small amount of hidden files, when it find references >> on files it wants to delete. This happens also under Linux and it is >> part of FUSE design, not much we can do. >> However, if deadlocks can be someway tollerated, things you should >> really pay attention are dumps of fuse modules (like ntfs-3g binary) >> and kernel panics. They must not happen and if they do they need to be >> fixed promptly. >> However, the good new is that ntfs seems doing exceptionally good. >> Florian could use ntfs as a backend for postgresql test. I think this >> is by far a big improvement if compared to current in-kernel ntfs >> which is completely torned. >> >> So far we have almost entirely tested only ntfs-3g. I know Gustau also >> used other modules like sshfs and George used GlusterFS with his older >> patches, but I encourage you to test as many modules as you want, as >> they may expose different bugs. Of course, I don't plan to spend much >> more time on FUSE, but I can occasionally look at bugs as they fall in >> the filesystems category and I'm always interested in keeping a good >> open eye on such issues. >> >> A few operational informations: >> - In the next days I will import the userland bits of fusefs-kmod to >> the fuse project branch making the port obsolete. When this happens I >> will make this clear to the user of this thread. >> - If no major bug is remained by the early October, I will commit this >> to -CURRENT >> - I expect Bryan and Florian to commit libfuse and ntfs updates soon. >> They can do independently from the fusefs-kmod retiral, but I would >> prefer their patches to go on first. >> - After that I will handover fusefs maintainership to gnn as agreed in >> precedence but I will be around helping with analysis and fixing, >> depending on time availability >> >> In the end I have really 2 minor questions: >> - One is about importing the mount_fusefs userland bits. I don't think >> we need a vendor import at all because they were developed by a >> FreeBSD GSoC student and kept in his git repo (or someone else's). >> Anyway, i'd just commit as new files once I do a good sweep. I hope >> nobody objects to that. >> - Another one is: fusefs-kmod right now is only amd64/i386 specific. I >> have no idea why as it has not any MD specific code. However I'm sure >> it has not been tested on other arches so far. Anyway I left it usable >> by all the arches. I think this is the correct choice. If someone >> objects with valid argument I can bring it back to be usable only on >> i386 and amd64. >> >> That's all, for any question please don't hesitate to contact me and >> the other people involved in this work. > > Attilio (and the crew), > > Thanks for working on fusefs-ntfs. It's been increasingly worrying to > me that we might lose it and I really depend on it. I really hope to > be able to use rsync to update files without killing my system some > day. > > I tried the new fusefs-libs and fusefs-ntfs ports from Florian and > Bryan, but ran into trouble as I could no longer build the kmod after > installing the updated fusefs-libs. It had an unresolved symbol: > cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE > -nostdinc -I../include -I. -I@ -I@/contrib/altq -finline-limit=8000 > --param inline-unit-growth=100 --param large-function-growth=1000 > -fno-common -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone > -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables > -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector > -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes > -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef > -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs > -fdiagnostics-show-option -c fuse_vnops.c > fuse_vnops.c: In function 'create_filehandle': > fuse_vnops.c:1586: error: 'struct fuse_open_in' has no member named 'mode' > *** [fuse_vnops.o] Error code 1 > > This was on amd64 9-Stable r239879 until/unless this issue is > resolved, please keep the existing port available and/or mark the new > one to not install on pre-10 systems. If you follow the rule I described in this e-mail, the fusefs-kmod kernel part won't be build anymore, so you won't run into this. If it is build yet, please let me know because there is a bug in the 2 patches I posted for fusefs-kmod port. Attilio -- Peace can only be achieved by understanding - A. Einstein