Make ZFS to use separate thread to handle SPA_ASYNC_REMOVE async events
zfs - Zettabyte File System
This issue was found by FreeBSD developer Alexander Motin <mav@FreeBSD.org>. The change was committed as FreeBSD r253990 ( http://svnweb.freebsd.org/changeset/base/253990 ), the commit message on FreeBSD was:
Make ZFS to use separate thread to handle SPA_ASYNC_REMOVE async events. Existing async thread is running only on successfull spa_sync() completion, that is impossible in case of pool loosing required (last) disk(s). That indefinite delay of SPA_ASYNC_REMOVE processing made ZFS to not close the lost disks, preventing GEOM/CAM from destroying devices and reusing names on later disk reattach. In earlier version of the patch I've tried to just run existing thread immediately, unrelated to spa_sync() completion, but that exposed number of situations where it could stuck due to locks held by stuck spa_sync(), that are required for other kinds of async events. Experiments with OpenIndiana snapshot confirmed that they also have this issue with lost disks reattach.