On Wed, May 11, 2005 at 12:35:39PM -0400, Luben Tuikov wrote: > I think Alan even wants to see the QUEUEFULL status not being > retried. > > That is, other than reclaiming the command from the LLDD, the > eh code should not retry or do anything with the command, just > pass it back to the user process who sent it via sg. > > Maybe the application client has other tricks up its sleeve > on QUEUEFULL coming from the device. > > I think scsi generic as a passthrough, where minimal logic > from SCSI Core is applied and most is left to the application > client. IMO, normal sg/SG_IO usage wants scsi core to requeue the request, they want the command to be processed by the LUN. And user space does not have the information available in scsi core (status of other outstanding IO to the same LUN), and can't retry in a timely manner, possibly avoid starvation issues. Maybe fast fail should be used to modify QUEUE FULL re-queue behaviours. It might be a bit odd in some cases and maybe hardware specific (for multi path io, does QUEUE FULL mean a storage port/controller is full, or the LUN is full? if port, then you want to send back to the upper level, but if LUN, you might want to let scsi core requeue it). -- Patrick Mansfield - : 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
