Project

General

Profile

Bug #4001

Make ZFS to use separate thread to handle SPA_ASYNC_REMOVE async events

Added by Xin Li about 7 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
zfs - Zettabyte File System
Start date:
2013-08-06
Due date:
% Done:

90%

Estimated time:
Difficulty:
Medium
Tags:
needs-triage
Gerrit CR:

Description

This issue was found by FreeBSD developer Alexander Motin <>. 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.

Files

253990.diff (4.46 KB) 253990.diff Xin Li, 2013-08-06 09:54 PM

Also available in: Atom PDF