How many retries to allow?

How many retries to allow?

[Alan Stern]

James and Boaz:

Here's a question.  Suppose a device returns NOT READY sense key 
repeatedly.  How long should the request be retried before we give up?  
If we never give up then the request will never finish, so the caller 
will hang.

Alan Stern

Re: How many retries to allow?

[Boaz Harrosh]

Alan Stern wrote:
> James and Boaz:
> 
> Here's a question.  Suppose a device returns NOT READY sense key 
> repeatedly.  How long should the request be retried before we give up?  
> If we never give up then the request will never finish, so the caller 
> will hang.
> 
> Alan Stern
> 
I always thought  request->retries was for that. Perhaps I misunderstood.

I think there should be one user settable global counter that will limit
all retries of any kind.

Just my $0.017
Boaz

Re: How many retries to allow?

[Alan Stern]

On Sun, 28 Sep 2008, Boaz Harrosh wrote:

> Alan Stern wrote:
> > James and Boaz:
> > 
> > Here's a question.  Suppose a device returns NOT READY sense key 
> > repeatedly.  How long should the request be retried before we give up?  
> > If we never give up then the request will never finish, so the caller 
> > will hang.
> > 
> > Alan Stern
> > 
> I always thought  request->retries was for that. Perhaps I misunderstood.

Maybe it is intended for that purpose, but it isn't being used as far 
as I can tell.  req->retries is never decremented; instead 
scmd->allowed is initialized to req->retries when the request is 
prepped.  But when a command fails and scsi_requeue_command() is 
called, the request is un-prepped and put back on the queue.  Then it 
is prepped again and a new scmd is created -- with the same number of 
retries as before.  Thus we will never run out of retries.

> I think there should be one user settable global counter that will limit
> all retries of any kind.

You're missing a major point.  Suppose for example that the device
returns NOT READY because a new medium is being loaded, a procedure
that takes a couple of seconds.  But the SCSI core doesn't wait between
retries; a new command is sent as soon as the old one fails.  A retry
limit of 10 could easily be used up in a fraction of a second, and then
the request would fail.

Is this how it's supposed to work?  Would it be better to invoke the 
error handler for this sort of thing?

Alan Stern

Re: How many retries to allow?

[Boaz Harrosh]

Alan Stern wrote:
> On Sun, 28 Sep 2008, Boaz Harrosh wrote:
> 
>> Alan Stern wrote:
>>> James and Boaz:
>>>
>>> Here's a question.  Suppose a device returns NOT READY sense key 
>>> repeatedly.  How long should the request be retried before we give up?  
>>> If we never give up then the request will never finish, so the caller 
>>> will hang.
>>>
>>> Alan Stern
>>>
>> I always thought  request->retries was for that. Perhaps I misunderstood.
> 
> Maybe it is intended for that purpose, but it isn't being used as far 
> as I can tell.  req->retries is never decremented; instead 
> scmd->allowed is initialized to req->retries when the request is 
> prepped.  But when a command fails and scsi_requeue_command() is 
> called, the request is un-prepped and put back on the queue.  Then it 
> is prepped again and a new scmd is created -- with the same number of 
> retries as before.  Thus we will never run out of retries.
> 

This sounds like a bug to me. It should be fixed. Perhaps it's there since 
the 2.6.18 changes when direct scsi_cmnd requeuing was eliminated. A test
would be most welcome. It should be easy to prove. I would if you don't bit
me to it. (Am pretty busy)

>> I think there should be one user settable global counter that will limit
>> all retries of any kind.
> 
> You're missing a major point.  Suppose for example that the device
> returns NOT READY because a new medium is being loaded, a procedure
> that takes a couple of seconds.  But the SCSI core doesn't wait between
> retries; a new command is sent as soon as the old one fails.  A retry
> limit of 10 could easily be used up in a fraction of a second, and then
> the request would fail.
> 
> Is this how it's supposed to work?  Would it be better to invoke the 
> error handler for this sort of thing?
> 

I always think of that as: timeout been the inner loop and retries on top
of that so 2-second-timeout, 5-retries, means 10 seconds. But now that you point
it out I can see how for some errors this breaks. A test with scsi_debug error
injection should be devised, to make sure things are fixed and don't regress in
the future.

I believe there are lots of theoretical catastrophes in current code, but
not too many in practice. Though, I agree that a pragmatic programing mindset
was practiced, over a more generalized one.

> Alan Stern
> 
> --

Sorry, I will not have time to conduct any tests in the near future, so you're on
your own. But I'll review anything you can post in the matter.

Thanks
Boaz

Re: How many retries to allow?

[Alan Stern]

On Sun, 28 Sep 2008, Boaz Harrosh wrote:

> This sounds like a bug to me. It should be fixed. Perhaps it's there since 
> the 2.6.18 changes when direct scsi_cmnd requeuing was eliminated. A test
> would be most welcome. It should be easy to prove. I would if you don't bit
> me to it. (Am pretty busy)

I'll do some testing soon.

> Sorry, I will not have time to conduct any tests in the near future, so you're on
> your own. But I'll review anything you can post in the matter.

I just posted three initial patches; you can review those for now.  
They straighten out existing issues but ignore the matter of limiting
the number of retries.

Alan Stern