Searched hist:253990 (Results 1 - 2 of 2) sorted by relevance
| /freebsd-11-stable/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/ | ||
| H A D | spa_impl.h | diff 253990 Tue Aug 06 12:24:36 MDT 2013 mav 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. |
| /freebsd-11-stable/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/ | ||
| H A D | spa.c | diff 253990 Tue Aug 06 12:24:36 MDT 2013 mav 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. |
Completed in 207 milliseconds