>> * It is possible to set the kernel timeouts higher than device retry
>> periods, if one does not care about latency, to minimize the chances
>> of declaring a drive failed (not the difference between Linux command
>> timeouts and retry timeouts, the latter can also be long).
> I don't have data on SSD behavior without ERC. If their retry
> cycle is exhausted within the kernel default 30 seconds, the
> timeout mismatch issue will *not* apply.
That as written may confuse readers as to the difference between
the Linux command timeout and the the Linux retry timeout:
# grep -H . /sys/module/scsi_mod/parameters/eh_deadline
/sys/module/scsi_mod/parameters/eh_deadline:-1
# grep -H . /sys/block/sda/device/*timeout*
/sys/block/sda/device/eh_timeout:10
/sys/block/sda/device/timeout:30
Things are different again with the NVME subsystem:
# grep -H . /sys/module/nvme_core/parameters/*{timeout,retries,latency}*
/sys/module/nvme_core/parameters/admin_timeout:60
/sys/module/nvme_core/parameters/io_timeout:30
/sys/module/nvme_core/parameters/shutdown_timeout:5
/sys/module/nvme_core/parameters/max_retries:5
/sys/module/nvme_core/parameters/default_ps_max_latency_us:100000
Some relevant links:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/managing_storage_devices/configuring-maximum-time-for-storage-error-recovery-with-eh_deadline_managing-storage-devices
https://unix.stackexchange.com/questions/541463/how-to-prevent-disk-i-o-timeouts-which-cause-disks-to-disconnect-and-data-corrup
https://elixir.bootlin.com/linux/v5.13.4/source/drivers/scsi/scsi_error.c
