Date: Wed, 3 Oct 2012 12:33:17 +0200 From: Baptiste Daroussin <bapt@FreeBSD.org> To: Andriy Gapon <avg@FreeBSD.org> Cc: freebsd-fs@FreeBSD.org, Florian Smeets <flo@smeets.im>, Pawel Jakub Dawidek <pjd@FreeBSD.org> Subject: Re: panic: _sx_xlock_hard: recursed on non-recursive sx zfsvfs->z_hold_mtx[i] @ ...cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c:1407 Message-ID: <20121003103317.GB6377@ithaqua.etoilebsd.net> In-Reply-To: <506BFA5B.9060103@FreeBSD.org> References: <505DB4E6.8030407@smeets.im> <20120924224606.GE79077@ithaqua.etoilebsd.net> <20120925090840.GD35915@deviant.kiev.zoral.com.ua> <20120929154101.GK1402@garage.freebsd.pl> <20120930122403.GB35915@deviant.kiev.zoral.com.ua> <506BFA5B.9060103@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--kORqDWCi7qDJ0mEj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 03, 2012 at 11:42:03AM +0300, Andriy Gapon wrote: > on 30/09/2012 15:24 Konstantin Belousov said the following: > > The postponing of the reclaim when vnode reserve goes low to the vnlru= =20 > > process does not solve anything, since you only change the recursion in= to=20 > > the deadlock. > >=20 > > I discussed an approach for this issue with avg. Basic idea is presente= d in > > the untested patch below. You can specify that some count of the free > > vnodes must be present for some dynamic scope, started by=20 > > getnewvnode_reserve() function. While staying inside the reserved pool, > > getnewvnode() calls would not recurse into vnlru(). The scope is finish= ed > > with getnewvnode_drop_reserve(). > >=20 > > The getnewvnode_reserve() shall be called while no locks are held. > >=20 > > What do you think ? >=20 > Here is a patch that makes use of the getnewvnode_reserve API in ZFS: > http://people.freebsd.org/~avg/zfs-getnewvnode.diff >=20 I can confirm that this patch solve the situation for me, I have been heavi= ly stressing it on my buildbox during all the night using poudriere and everyt= hing worked where previously failed quite fastly. regards, Bapt --kORqDWCi7qDJ0mEj Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlBsFG0ACgkQ8kTtMUmk6EycwQCgj8wMjdgQYY6PHC0xF+DLJUPU fuMAnjAnnFog/EwZzbwhRXJhnKX7RepZ =hXmh -----END PGP SIGNATURE----- --kORqDWCi7qDJ0mEj--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20121003103317.GB6377>