[dm-devel] How about shortening SCSI timeout value dynamically?

[James.Smart at Emulex.Com]

> 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
connectivity.
 
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).
 
-- james
-----Original Message-----
From: dm-devel-bounces at redhat.com [mailto:dm-devel-bounces at redhat.com]On Behalf Of gauri at etri.re.kr
Sent: Monday, September 12, 2005 10:52 PM
To: dm-devel at redhat.com
Subject: [dm-devel] How about shortening SCSI timeout value dynamically?


Under the multipath environment, when the path is determined to fail, we have to wait 30 seconds because of the SCSI command default timeout(30 seconds). If the multiple paths are alive, I think it is more efficient to short the SCSI command timeout. Then we can shorten the delay of failover.
Is there any critical reason to remain SCSI timeout as a 30 seconds?
 
What do you think about my this?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/dm-devel/attachments/20050913/732c6ba1/attachment.htm>