Date: Tue, 25 Sep 2012 12:08:40 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Baptiste Daroussin <bapt@freebsd.org> Cc: freebsd-fs@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: <20120925090840.GD35915@deviant.kiev.zoral.com.ua> In-Reply-To: <20120924224606.GE79077@ithaqua.etoilebsd.net> References: <505DB4E6.8030407@smeets.im> <20120924224606.GE79077@ithaqua.etoilebsd.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--mSxgbZZZvrAyzONB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 25, 2012 at 12:46:07AM +0200, Baptiste Daroussin wrote: > Hi, >=20 > I have the exact same problem making: tinderbox and poudriere highly > unusable. > > This is really problematic because pointyhat also rely on nullfs and > zfs, which means we can't upgrade the building nodes if we need to for > example. > > regards, Bapt This is zfs bug. Filesystems shall not call getnewvnode() while holding internal locks. At least not the locks which are needed during reclaim. Nullfs changes amplified the probability of the problematic situation, since now nullfs vnodes are indeed cached instead of being recreated on each access, so the overall count of used vnodes could be twice as high. You might try to increase the kern.maxvnodes to reduce the probability of the recursive calls into vnlnru() from getnewvnode(). But for real, bug needs to be fixed in zfs. --mSxgbZZZvrAyzONB Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlBhdJgACgkQC3+MBN1Mb4hRygCfUgeh70w08J1a8gv3NRA84KUU R50AoM5Kh0P1nAzzDlC6YfPA8ds+2Bz0 =VXTg -----END PGP SIGNATURE----- --mSxgbZZZvrAyzONB--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120925090840.GD35915>