From owner-freebsd-fs@FreeBSD.ORG Mon Jul 2 20:12:12 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A1341065673; Mon, 2 Jul 2012 20:12:12 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 2E39C8FC1A; Mon, 2 Jul 2012 20:12:10 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q62KCJ8A033019; Mon, 2 Jul 2012 23:12:19 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q62KC77s099146; Mon, 2 Jul 2012 23:12:07 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q62KC6PH099145; Mon, 2 Jul 2012 23:12:06 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 2 Jul 2012 23:12:06 +0300 From: Konstantin Belousov To: Alexander Kabaev Message-ID: <20120702201206.GV2337@deviant.kiev.zoral.com.ua> References: <20120702061219.GA16671@infradead.org> <20120702150339.GA7226@kan.dyndns.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0l0ctNieuEHM0Mkh" Content-Disposition: inline In-Reply-To: <20120702150339.GA7226@kan.dyndns.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Attilio Rao , "C. P. Ghost" , Russell Cattelan , freebsd-current@freebsd.org, FreeBSD FS 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: Mon, 02 Jul 2012 20:12:12 -0000 --0l0ctNieuEHM0Mkh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 02, 2012 at 11:03:40AM -0400, Alexander Kabaev wrote: > On Mon, Jul 02, 2012 at 02:12:20AM -0400, Christoph Hellwig wrote: > > On Sun, Jul 01, 2012 at 03:52:05PM +0200, Attilio Rao wrote: > > > anything by SoC involved people about NTFS and certainly I don't see a > > > plan to get XFS locked. > >=20 > > Stupid question, but what amount of locking does XFS in FreeBSD still > > need? I'm one of the maintainer of XFS on Linux, and while I know > > FreeBSD imported a really old version compared to the current one the > > codebases on IRIX and later Linux never relied on any global Giant-style > > locking. So if there is anything to fix it would be the in the small > > bits of FreeBSD-specific code. > >=20 >=20 > When I stopped being interested in XFS, I left is marked as non-MPSAFE > entirely because of the lack of proper testing and because VFS locking > was still evolving, there was no officially proper way of locking the > FS and no other FS in the tree was MPSAFE. At that time the only > problematic area was around inode instantiation, but sereval other > lockingi changes have made it into the tree since then, namely ones that > deal with insmntque and also VOP_LOOKUP changes. To mark XFS MPSAFE, one > needs to simply audit the code and make sure it still makse sense for tod= ay's > VFS, which is not a huge amount of work. One step further woule be to take > most of the XFS from under the exclusive vnode locking to improve the > performance. If filesystem uses some global internal locks, that locks usually are placed after the vnode locks in global lock order, because VOP methods call into fs with vnode locked. Then, VOP_LOOKUP() usual sequence of events, when method is called with lookup directory locked, causes LOR. It appears because you lock global lock upon entry into VOP_LOOKUP(), and then need to lock the returned vnode. Dropping global lock inside VOP_LOOKUP() usually exposes races which were the reason to introduce the global lock. Having filesystem non-MPSAFE makes the LOR go away without the need to drop global lock. Example of FreeBSD native filesystem which suffered from this issue and required quite non-trivial handling is devfs. Devfs uses per-mount global lock. See devfs_allocv() and devfs_allocv_drop_refs() for the gory details. --0l0ctNieuEHM0Mkh Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk/yAJYACgkQC3+MBN1Mb4jGHQCfbUFjkOyR04wK/OubK1LWcRW/ hZsAoIk6tJQ2niBpuL3/3OmDFvfLL9hq =lP1N -----END PGP SIGNATURE----- --0l0ctNieuEHM0Mkh--