RE: Transport affected timeouts...

Smart, James
2004-04-16T19:40:01Z

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.

-- james

> -----Original Message-----
> From: James Bottomley [mailto:James.Bottomley@SteelEye.com]
> Sent: Friday, April 16, 2004 3:24 PM
> To: Smart, James
> Cc: Linux SCSI Reflector
> Subject: Re: Transport affected timeouts...
>
>
> On Fri, 2004-04-16 at 10:40, Smart, James wrote:
> > One issue that we're wrestling with in our driver is
> timeout values. In the
> > past, we've encountered large configurations where the
> timeouts from the
> > midlayer are insufficient. In general - we'd like the scsi
> host to be able
> > to add a transport/topology increment time to the base
> timeout values. The
> > methodology would have to be dynamic as it may change as
> link connectivity
> > changes.
> >
> > Obviously, an hba driver mucking with the timeout values
> handed to it is
> > frowned upon. Is there a recommendation on how we should
> handle this ?
>
> There's no currently agreed upon framework, but would
>
> http://www-124.ibm.com/storageio/ipr/patch-2.6.5-sd_timeout_mod
>
> Do for what you want?
>
> James
>
>