RE: Transport affected timeouts...

Smart, James
2004-04-16T20:13:16Z

> -----Original Message-----
> From: James Bottomley [mailto:James.Bottomley@SteelEye.com]
> Sent: Friday, April 16, 2004 3:47 PM
> To: Smart, James
> Cc: Linux SCSI Reflector
> Subject: RE: Transport affected timeouts...
>
>
> On Fri, 2004-04-16 at 14:39, Smart, James wrote:
> > I had looked at the patch. I don't think it works as well as the
> > incrementer. But it would be a start. We would need the st
> driver, and scsi
> > generic to use it as well. It doesn't address the timeout
> changing post
> > slave_configure. The other thing that bothers me is that it
> uses an explicit
> > value. As per the thread, it would have been better to know what the
> > original default was and just increment/double it - and
> there is the issue
> > of different device types needing different defaults.
>
> I don't think it's a good idea to alter *every* timeout, merely the
> usual ones (hence, really only read and write in the patch).

In general, we're reflecting larger/longer topologies that just induce more
latency in performing an i/o and which can have an aggregate effect overall
to i/o queued in/for the target. Didn't matter whether it was an usual i/o
or not.

>
> Why do you need it to be variable post slave_configure?

Hmm... the gist of the argument is that the adapter could be replugged to
another fabric that has larger or lower timeouts needed. But - I would
assume a midlayer rescan would have to occur on such a change. New devices
are covered as slave_configure would be called for them. But, is
slave_configure called again on existing devices that change "personality"
as they are now a different physical device?

-- james