On Mon, 2016-03-07 at 11:40 -0500, James Bottomley wrote: > On Mon, 2016-03-07 at 00:03 -0800, Nicholas A. Bellinger wrote: > > On Mon, 2016-03-07 at 08:55 +0100, Christoph Hellwig wrote: > > > On Sun, Mar 06, 2016 at 01:55:15PM -0800, Nicholas A. Bellinger > > > > So as-is this might be well intended but either useless or broken. > > > -- > > > > No, it useful for hosts that have an aggressive SCSI timeout, and it > > works as expected with Linux/SCSI hosts that either retry on BUSY > > status, or retry + reduce queue_depth on TASK_SET_FULL status. > > I'm with Christoph on this: BUSY and QUEUE_FULL are already handled > generically in SCSI. All drivers should use the generics: to handle > separately, the driver has to intercept the error code, which I thought > I checked that none did (although it was a while ago). Additionally, > the timeout on these operations is retries * command timeout. So for > the default 5 retries and 30 seconds, you actually get to tolerate > BUSY/QUEUE_FULL for 2.5 minutes before you get an error. If this is a > problem, you can bump up the timer in > > /sys/class/scsi_device/<id>/device/timeout > Yes, Linux/SCSI hosts have a sane default timeout + retries, and aren't the ones who really need SAM_STAT_BUSY + SAM_STAT_TASK_SET_FULL responses intermittently to avoid going nuts. It's for ESX 5+ hosts, that with iscsi use a hard-coded (non user configurable) timeout of 5 seconds, before attempting ABORT_TASK and friends. For FC, it's LLD dependent, and IIRC the default for qla2xxx is 20 seconds. -- 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
