> Is there a critical reason to leave the SCSI timeout at 30 seconds ?
Yes, On busy arrays (lots of queued command), even 30 seconds is not sufficient. Our testing on heavily loaded arrays
says i/o timeouts should actually be in the 60 second range. These measurements were on standard single-path
configs. You could argue that multipath configs make the queuing worse. Also, background array tasks, such as
driver rebuilds, etc will increase the normal i/o execution times.
This said, smart administrators should be monitoring i/o load, adjusting queue depths, etc so that things aren't in the
range of 30 seconds. However, with multipathing in the mix, this becomes a much more difficult task for the admin.
Please note: it is bad to assume what the command execution time latency is based simply on having physical
My personal opinion is that you really want a "cancel i/o" interface. This way, at least when you get notified of
the loss of connectivity, you can cancel the remaining i/o's and failover quicker. I would assume, in much the same way
as the generic status codes are being handled, the block layer can be expanded to add this interface (and call the
SCSI abort handler, which already exists).