On Wed, Sep 26, 2012 at 7:20 PM, Martin K. Petersen <martin.petersen@xxxxxxxxxx> wrote: >>>>>> "James" == James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> writes: > > James> On Mon, 2012-09-24 at 17:00 -0400, Jeff Garzik wrote: >>> >>> drivers/scsi/sd.c | 4 ++++ drivers/scsi/sd.h | 2 +- 2 files changed, >>> 5 insertions(+), 1 deletion(-) > > James> I'm not opposed in principle to doing this (except that it should > James> be a sysfs parameter like all our other controls), > > Now that we're in that department. I never got any feedback on the > following patch. > > Hannes told me in person that he felt the eh_timeout belonged in > scsi_device and not in the request queue. Whereas I favored making it a > block layer tunable despite currently only being used by SCSI. Any > opinions? > I think request_queue since tuning these parameters would be useful for libata/libsas usage and libata is still on track to move out from under scsi ;-). Hm, how to extend this for the ata eh case? I had a global hack to make libata give up quicker [1], but I it would be better to have it be per queue. What about another tunable to limit how deep into the recovery escalation to go? For pure scsi it short circuits escalation and for ata it limits tries ata_eh_reset(), and then the value of eh_timeout_secs in the non-default case overrides those in ata_eh_reset_timeouts.. -- Dan [1]: "libata: reset once" http://marc.info/?l=linux-ide&m=134189240724489&w=2 ...Dave found this does not work as advertised for libsas since we don't end up applying force parameters to sas-ata links. My test case apparently fell out of eh early for another reason. -- 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
