From owner-freebsd-fs@FreeBSD.ORG Mon Jul 2 22:18:02 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 26449106564A; Mon, 2 Jul 2012 22:18:02 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 961348FC12; Mon, 2 Jul 2012 22:18:01 +0000 (UTC) Received: by qcsg15 with SMTP id g15so3709155qcs.13 for ; Mon, 02 Jul 2012 15:18:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; bh=YA229ZxuTLp7wYV3QgrlsfH1OApy1puoZbXNkWpw698=; b=AwjMYg/h0PYOhGM2qZGbOfy2ODnu/4UQt4uD8YWgcpy2mh78yQ4Gl+z174ZHZeajUM dkWx1y/YVyd+qtn5/aOhcgDohf+AXpGaTRK0x12dDNU9boqKmrxqRBJpyuOAqK5XAiGA Pn3F6p2LlQaLkDJPeKoK+J+YUg1pjgY+M0wKCkkSsUeXnsZTru11X0dtDLJSBHiD9paG so2i30F+S5x+bUnuEl050dQkFqJUAmqr3rYUqNT7YT4TOagp4X4WGom3bzRS3uzeMJ2h Uo+PANayujtO3NlFJwvVstNm3XUvzUgc8Vo8BuMe1henDuqBVyM/UQus4OgZh7WPs1WF mkmw== Received: by 10.224.181.6 with SMTP id bw6mr25970184qab.74.1341267480796; Mon, 02 Jul 2012 15:18:00 -0700 (PDT) Received: from kan.dyndns.org (c-24-63-226-98.hsd1.ma.comcast.net. [24.63.226.98]) by mx.google.com with ESMTPS id cz12sm33957314qab.5.2012.07.02.15.17.59 (version=SSLv3 cipher=OTHER); Mon, 02 Jul 2012 15:17:59 -0700 (PDT) Date: Mon, 2 Jul 2012 18:17:48 -0400 From: Alexander Kabaev To: Konstantin Belousov Message-ID: <20120702181748.6bb126f6@kan.dyndns.org> In-Reply-To: <20120702201206.GV2337@deviant.kiev.zoral.com.ua> References: <20120702061219.GA16671@infradead.org> <20120702150339.GA7226@kan.dyndns.org> <20120702201206.GV2337@deviant.kiev.zoral.com.ua> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/tC9gBXvdben2oNR.d08Mkfp"; protocol="application/pgp-signature" 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 22:18:02 -0000 --Sig_/tC9gBXvdben2oNR.d08Mkfp Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Mon, 2 Jul 2012 23:12:06 +0300 Konstantin Belousov wrote: > 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 today'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. >=20 > 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. >=20 > 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. All very informative, though misplaced in case of XFS. XFS does not use global lock internally, it is quite well locked inside and exclusive _VNODE_ lock we take by default in all methods is usually unnecessary as all it does it prevents other locks in XFS proper from having any useful function. --=20 Alexander Kabaev --Sig_/tC9gBXvdben2oNR.d08Mkfp Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iD8DBQFP8h4VQ6z1jMm+XZYRAhbnAJwJ9FKxAHEhZQS3re4WJZZA5Jr4+wCcCXv8 AA5y7bwN5mHu/RbP0pxXh1M= =u2RK -----END PGP SIGNATURE----- --Sig_/tC9gBXvdben2oNR.d08Mkfp--