Opened 6 years ago
Last modified 3 years ago
#1066 new enhancement
Please add a timeout parameter
Reported by: | Philipp Guehring | Owned by: | |
---|---|---|---|
Priority: | minor | Milestone: | unscheduled |
Component: | smartctl | Version: | 7.2 |
Keywords: | Cc: | Jinoh Kang |
Description
I am trying to debug a SSD firmware, which takes longer than the hardcoded timeouts in smartctl permits. Could you please add a commandline parameter to smartctl so that I can specify or even disable the timeout when needed?
Change History (8)
comment:1 by , 6 years ago
Keywords: | timeout removed |
---|---|
Milestone: | → undecided |
Priority: | trivial → minor |
comment:2 by , 6 years ago
5 hours is sufficient for debugging, but the 60 seconds are the problem that I have. Currently, I am using a SATA SSD on an iMX6 SATA controller on ARM. I succeeded to change the kernel default with "echo 1000000 >/sys/block/sda/device/timeout" for all other commands I have been testing now, only smartctl . Since I have optimized the JTAG interfaces, most sessions take less than an hour now, before that, I sometimes had workloads that took days.
comment:3 by , 6 years ago
The command I am currently using is "smartctl -r ioctl,2 -a /dev/sda --identify".
As far as I have seen, the 60 seconds timeout is defined centrally, so if you can override it with a commandline parameter before the other modules are using it, that should help for most platforms, I guess.
comment:4 by , 6 years ago
Milestone: | undecided → unscheduled |
---|
The SCSI timeout is defined centrally as SCSI_TIMEOUT_DEFAULT
in scsicmds.h. This is also used for SAT such that is also affects default (S)ATA access on Linux. Other ATA, NVMe and RAID controller timeouts not defined centrally (for example see r4750).
We possibly add a --timeout=SECONDS
option in the future after adding a timeout setting also to ATA and NVMe pass-through structs. I only see two rare use cases for long timeouts: CAPTIVE/FOREGROUND self-tests and drive firmware debugging (see also ticket #832). Both are not relevant for the typical smartmontools user.
For the short term, please consider to set SCSI_TIMEOUT_DEFAULT
to the desired value and then compile a custom version of smartctl.
comment:5 by , 5 years ago
Side note - not every interface allow to set timeouts, e.g. all high-level interfaces (like in Darwin) handling this internally.
comment:6 by , 4 years ago
Cc: | added |
---|---|
Version: | 6.6 → 7.2 |
On the other hand, the current behavior might not be the most consistent choice either, as it uses SCSI_TIMEOUT_DEFAULT
for supported platforms and the system default for others.
How about the following (either or both):
- Add flag
--default-timeout
,--timeout=default
,--timeout=system-default
, or--use-system-timeout
, which would revert to system default rather than useSCSI_TIMEOUT_DEFAULT
. On Linux this is configurable viaSG_[GS]ET_TIMEOUT
(notrq_timeout
). - Fail if
--timeout
is specified, but the system does not support specifying a non-default timeout.
comment:7 by , 4 years ago
Milestone: | unscheduled → Release 7.3 |
---|
Selection of system default could also be done with --timeout=0
.
comment:8 by , 3 years ago
Milestone: | Release 7.3 → unscheduled |
---|
In most cases, timeouts are set to 60 seconds or 0 (kernel default). For SCSI_SEND_DIAGNOSTIC, timeout is set to 5 hours. I agree that this might not be suitable for all uses cases.
Adding a generic timeout setting that covers all protocols (ATA, SCSI, NVMe), all supported platforms with all supported RAID controllers would be non-trivial.
For which specific configuration (protocol, drive command, platform) do you need longer timeouts?