On Fri, 2007-02-02 at 16:54 -0600, James Bottomley wrote: > On Fri, 2007-02-02 at 17:04 -0500, Edward Goggin wrote: > > Patch Set Summary: > > > > 1 Define new SCSI ML host status DID_COND_REQUEUE and > > add its handling code to scsi_decide_disposition. > > Scsi_decide_disposition returns ADD_TO_MLQUEUE IFF > > not REQ_FAILFAST. > > > > 2 Return DID_COND_REQUEUE instead of DID_BUS_BUSY host status > > in MPT fusion driver when IOC status is SUCCESS and scsi > > status is busy. > > Please, no. > > In the first place, as I already said on the previous thread, I don't > think the driver should be interpreting the BUSY return. > > Secondly, the original problem was with fibre devices which seemed to > want FAILFAST on BUSY (which looks very bogus to me), but no-one asked > for this behaviour to be preserved. The original bug report: > > "When a target device responds with BUSY status, the MPT driver > was > sending DID_OK to the SCSI mid layer, which caused the IO to be > retried indefinitely betweenthe mid layer and the > driver. By changing the driver return status to DID_BUS_BUSY, > the target BUSY status can now flow through the mid layer to an > upper layer Failover driver, whichwill manage the I/O timeout." > > is about behaviour which is now fixed (BUSY is retried for the command's > maximum lifetime but no longer). > > Thirdly, the VMware issue was that the fibre fix was causing your > implementation to time out too fast. > > The solution, then, as I said previously should simply be to pass the > BUSY status up unmodified from the fusion driver. > That solution doesn't work for the RDAC/MPP driver as the BUSY status handler retries indefinitely. We need a solution which works for both a bare metal host running RDAC/MPP which for this use case, wants to get control over the failed command ASAP and a VMware host which may need to retry longer than DID_BUS_BUSY currently allows for. I'll let the LSI/Engenio people comment further on their needs. > James > > > - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
