[Bug 241980] panic: I/O to pool appears to be hung on vdev

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241980

--- Comment #4 from Eugene Grosbein <eugen at freebsd.org> ---
spa_misc.c:

/*
 * Expiration time in milliseconds. This value has two meanings. First it is
 * used to determine when the spa_deadman() logic should fire. By default the
 * spa_deadman() will fire if spa_sync() has not completed in 1000 seconds.
 * Secondly, the value determines if an I/O is considered "hung". Any I/O that
 * has not completed in zfs_deadman_synctime_ms is considered "hung" resulting
 * in a system panic.
 */
uint64_t zfs_deadman_synctime_ms = 1000000ULL;]

Is it possible that queue of ATA TRIM requests grows faster than underlying
SSDs erase their cells physically, so timeout fires eventually? And da2 is just
first component of the pool.

SMART Extended offline test passed successfully for da2.

-- 
You are receiving this mail because:
You are the assignee for the bug.