Date: Sun, 5 Feb 2017 17:41:13 +0100 From: Fabian Keil <freebsd-listen@fabiankeil.de> To: "Matthew X. Economou" <xenophon@irtnog.org> Cc: <freebsd-stable@freebsd.org> Subject: Re: Swapping from a zvol results in a deadman panic Message-ID: <20170205174113.5858bc99@fabiankeil.de> In-Reply-To: <BABF8C57A778F04791343E56016599082370A1@cinip100ntsbs.irtnog.net> References: <BABF8C57A778F04791343E56016599082370A1@cinip100ntsbs.irtnog.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--Sig_/yAExqy3EP3MeNaxCSNqrcQG Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable "Matthew X. Economou" <xenophon@irtnog.org> wrote: > My FreeBSD 10.3-RELEASE-p16 server crashes in the middle of a Poudriere > bulk run (see below). This crash happens even if I lower > vfs.zfs.arc_max or tweak vm.v_free_min/target/reserved/severe. I'm > looking for configuration advice in case I missed something obvious, > since this seems to work on Illumos- and Linux-derived O/Ses, but > failing that, I'd like to get some advice as to how to go about > debugging this. I doubt the deadman timer causes the system to stop > responding. It's more likely a race condition elsewhere. >=20 > The pool itself uses 4k sectors and is geli-encrypted. I configured the > swap zvol based on root-on-ZFS install instructions found in the FreeBSD > wiki: Paging on geli-encrypted devices is known to cause deadlocks on FreeBSD, even if ZFS isn't involved directly: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D209759 Adding ZFS to the mix is unlikely to help ... > zfs create -V 6G -o org.freebsd:swap=3Don -o checksum=3Doff -o > compression=3Doff -o dedup=3Doff -o sync=3Ddisabled -o primarycache=3Dnone > zroot/swap >=20 > The ZoL wiki recommends a slightly different zvol configuration: >=20 > zfs create -V 4G -b $(getconf PAGESIZE) -o logbias=3Dthroughput -o > sync=3Dalways -o primarycache=3Dmetadata -o com.sun:auto-snapshot=3Dfalse > rpool/swap >=20 > I'm not sure how much of this applies to FreeBSD due to differences in > kernel design/implementation. Does anyone have an idea of what might be > going on and how I might get this working? You could try the patch from the PR and enable the kern.geom.eli.use_uma_for_all_writes sysctl. If you have a core dump, you may want to confirm that the g_eli_worker is waiting for memory first. Fabian --Sig_/yAExqy3EP3MeNaxCSNqrcQG Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQTKUNd6H/m3+ByGULIFiohV/3dUnQUCWJdVqgAKCRAFiohV/3dU nf37AKCZzGs59aA9nNs9jnNwmgb9nxQHFwCeNHoGLwVakcB8DFKV53C46iHNGVY= =JzFx -----END PGP SIGNATURE----- --Sig_/yAExqy3EP3MeNaxCSNqrcQG--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170205174113.5858bc99>