Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 2 Jul 2012 18:17:48 -0400
From:      Alexander Kabaev <kabaev@gmail.com>
To:        Konstantin Belousov <kostikbel@gmail.com>
Cc:        Attilio Rao <attilio@freebsd.org>, "C. P. Ghost" <cpghost@cordula.ws>, Russell, Christoph Hellwig <hch@infradead.org>, Cattelan <cattelan@thebarn.com>, freebsd-current@freebsd.org, FreeBSD FS <freebsd-fs@freebsd.org>
Subject:   Re: MPSAFE VFS -- List of upcoming actions
Message-ID:  <20120702181748.6bb126f6@kan.dyndns.org>
In-Reply-To: <20120702201206.GV2337@deviant.kiev.zoral.com.ua>
References:  <CAJ-FndAJtFx_OhqzDvBSLQ5pEaX730oF8Tbyk%2BkYbz9y1KaXXA@mail.gmail.com> <CADGWnjXPtF1g1YXWEie3VAhamjj3D_MQ89Ep4zh3_6g8tGHzAA@mail.gmail.com> <CAJ-FndDRvZdzF00hO6TWJMASDmpgK4mkF3GFsacF3KBSB00YWw@mail.gmail.com> <20120702061219.GA16671@infradead.org> <20120702150339.GA7226@kan.dyndns.org> <20120702201206.GV2337@deviant.kiev.zoral.com.ua>

next in thread | previous in thread | raw e-mail | index | archive | help
--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 <kostikbel@gmail.com> 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--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120702181748.6bb126f6>