Swapping from a zvol results in a deadman panic

[Fabian Keil]

"Matthew X. Economou" <xenophon at 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.
> 
> 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=209759

Adding ZFS to the mix is unlikely to help ...

> zfs create -V 6G -o org.freebsd:swap=on -o checksum=off -o
> compression=off -o dedup=off -o sync=disabled -o primarycache=none
> zroot/swap
> 
> The ZoL wiki recommends a slightly different zvol configuration:
> 
> zfs create -V 4G -b $(getconf PAGESIZE) -o logbias=throughput -o
> sync=always -o primarycache=metadata -o com.sun:auto-snapshot=false
> rpool/swap
> 
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20170205/accd3e3e/attachment.sig>