On Sat, 2005-01-29 at 11:34 -0800, Patrick Mansfield wrote:
On Sat, Jan 29, 2005 at 10:44:41AM -0600, James Bottomley wrote:
On Fri, 2005-01-28 at 21:46 -0800, Andrew Vasquez wrote:
Returning back DID_IMM_RETRY for these 'transport' related conditions
would of course help in this issue --
On Mon, Jan 31, 2005 at 11:56:02AM -0500, [EMAIL PROTECTED] wrote:
On Sat, 2005-01-29 at 11:34 -0800, Patrick Mansfield wrote:
Why not just set scmd-retries to zero in scsi_requeue_command()?
This is exactly what I was thinking would be a fairly straight-forward
approach at
On Mon, 2005-01-31 at 11:56 -0500, [EMAIL PROTECTED] wrote:
On Sat, 2005-01-29 at 11:34 -0800, Patrick Mansfield wrote:
On Sat, Jan 29, 2005 at 10:44:41AM -0600, James Bottomley wrote:
On Fri, 2005-01-28 at 21:46 -0800, Andrew Vasquez wrote:
Returning back DID_IMM_RETRY for these
If the transport hits a problem, there's
no harm done as long as the problem is resolved within the block
timeout. If the timeout is hit - it's because the user dicated that
it wanted to know of errors within this time and if the
device fails,
it fails...
In the multipath
On Mon, 2005-01-31 at 09:36 -0800, Patrick Mansfield wrote:
On Mon, Jan 31, 2005 at 11:56:02AM -0500, [EMAIL PROTECTED] wrote:
On Sat, 2005-01-29 at 11:34 -0800, Patrick Mansfield wrote:
Why not just set scmd-retries to zero in scsi_requeue_command()?
This is exactly
On Fri, 2005-01-28 at 21:46 -0800, Andrew Vasquez wrote:
Returning back DID_IMM_RETRY for these 'transport' related conditions
would of course help in this issue -- but at the same time bring with it
several side-effects which may not be desirable.
So, beyond this particular circumstance,
On Sat, Jan 29, 2005 at 10:44:41AM -0600, James Bottomley wrote:
On Fri, 2005-01-28 at 21:46 -0800, Andrew Vasquez wrote:
Returning back DID_IMM_RETRY for these 'transport' related conditions
would of course help in this issue -- but at the same time bring with it
several side-effects which
On Sat, 2005-01-29 at 11:34 -0800, Patrick Mansfield wrote:
But the transport hit a failure, not the storage device.
I thought Andrew hit this sequence:
- pull / replace cable
- IO resumes but gets NOT_READY (the device could be logging back
into the fibre or such)
Patrick Mansfield wrote:
On Sat, Jan 29, 2005 at 10:44:41AM -0600, James Bottomley wrote:
On Fri, 2005-01-28 at 21:46 -0800, Andrew Vasquez wrote:
Returning back DID_IMM_RETRY for these 'transport' related conditions
would of course help in this issue -- but at the same time bring with it
several
On Fri, 2005-01-28 at 15:24 -0800, Andrew Vasquez wrote:
...
There seems to be two problem with this approach:
1. As the storage continues to return NOT_READY,
scsi_decide_disposition() blindly increments cmd-retries and
checks against cmd-allowed, returning
10 matches
Mail list logo
