Set spa_ccw_fail_time=0 when expanding a vdev.
commitea30b5a9e0d266baa13398ed8f9435de050f4b25
authorColin Percival <cperciva@tarsnap.com>
Fri, 20 Oct 2023 17:30:32 +0000 (20 10:30 -0700)
committerGitHub <noreply@github.com>
Fri, 20 Oct 2023 17:30:32 +0000 (20 10:30 -0700)
tree017412baebdca00667725ef871d4bb6c35483cb6
parentf0f330e1212ee3924a3eadbdb40e7d71e0fb0a69
Set spa_ccw_fail_time=0 when expanding a vdev.

When a vdev is to be expanded -- either via `zpool online -e` or via
the autoexpand option -- a SPA_ASYNC_CONFIG_UPDATE request is queued
to be handled via an asynchronous worker thread (spa_async_thread).
This normally happens almost immediately; but will be delayed up to
zfs_ccw_retry_interval seconds (default 5 minutes) if an attempt to
write the zpool configuration cache failed.

When FreeBSD boots ZFS-root VM images generated using `makefs -t zfs`,
the zpoolupgrade rc.d script runs `zpool upgrade`, which modifies the
pool configuration and triggers an attempt to write to the cache file.
This attempted write fails because the filesystem is still mounted
read-only at this point in the boot process, triggering a 5-minute
cooldown before SPA_ASYNC_CONFIG_UPDATE requests will be handled by
the asynchronous worker thread.

When expanding a vdev, reset the "when did a configuration cache
write last fail" value so that the SPA_ASYNC_CONFIG_UPDATE request
will be handled promptly.  A cleaner but more intrusive option would
be to use separate SPA_ASYNC_ flags for "configuration changed" and
"try writing the configuration cache again", but with FreeBSD 14.0
coming very soon I'd prefer to leave such refactoring for a later
date.

Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Colin Percival <cperciva@FreeBSD.org>
Closes #15405
module/zfs/vdev.c