Date: Fri, 13 Jul 2012 00:18:12 +0100 From: Attilio Rao <attilio@freebsd.org> To: FreeBSD FS <freebsd-fs@freebsd.org>, freebsd-current@freebsd.org, Peter Holm <pho@freebsd.org>, =?UTF-8?Q?Gustau_P=C3=A9rez?= <gperez@entel.upc.edu>, George Neville-Neil <gnn@freebsd.org> Subject: Re: MPSAFE VFS -- List of upcoming actions Message-ID: <CAJ-FndBzoeXpFFHEmhiYZ9er=n0zXSXXo-vbrLX4ZmYdjDQMhg@mail.gmail.com> In-Reply-To: <CAJ-FndC=3Z9hNAHR9cwwypxhx%2Be27%2B6eiHWxOxRBij8H_wLb6w@mail.gmail.com> References: <CAJ-FndAJtFx_OhqzDvBSLQ5pEaX730oF8Tbyk%2BkYbz9y1KaXXA@mail.gmail.com> <CAJ-FndC=3Z9hNAHR9cwwypxhx%2Be27%2B6eiHWxOxRBij8H_wLb6w@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 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 I'm now looking for people sticking with the branch and trying to stress-test ntfs-3g as much as they can. For example I know that Gustau (cc'ed) already had issues. It would be good if he tries to reproduce them and make a full report. Please try to stick with the code contained with this branch for the tests unless diversly advised. As final note, George as agreed to maintain FUSE in the long-term and of course I'll give him an hand as time permits. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-FndBzoeXpFFHEmhiYZ9er=n0zXSXXo-vbrLX4ZmYdjDQMhg>