RE: [PATCH]: Flexible timeout infrastructure

Smart, James
2004-06-16T18:06:28Z

So the jist isn't to get the command to survive the LLDD event, even if it
could. Rather, the user has set aside X amount of time (where X = #retries *
timeout length), and you want to return the command to the user as close to
X as possible. And there are 2 further expectations: you are willing to
suffer the failure of non-retryable commands that may be forced to fail; and
you expect the LLDDs to call the midlayer to block further commands if the
LLDD event persists. (Note: this is where I think more granularity could be
used - instead of host-global events, there may be target-specific events as
well).

Ok. Just trying to get on the same page...

-- james

> -----Original Message-----
> From: James Bottomley [mailto:James.Bottomley@SteelEye.com]
> Sent: Wednesday, June 16, 2004 1:38 PM
> To: Smart, James
> Cc: Luben Tuikov; Mike Anderson; SCSI Mailing List
> Subject: RE: [PATCH]: Flexible timeout infrastructure
>
>
> On Wed, 2004-06-16 at 12:33, Smart, James wrote:
> > I'll try to restate. The patch proposed to allow only 1
> restart of the timer
> > for a command. My comment was - why not 2, or 3? I would
> think - the number
> > of restarts needed is a function of how long the timeout
> value is vs when
> > the LLDD event occurs and what the duration of the LLDD
> event is. I can see
> > capping the number of timer restarts, but am not sure 1 is
> the best choice.
>
> It does. But the number of allowed restarts is linked to the command
> retries (actually allowed retries + 1).
>
> James
>
>