Re: [SCSI PATCH] sd: max-retries becomes configurable

On Wed, Sep 26, 2012 at 7:20 PM, Martin K. Petersen
[off-list ref] wrote:

quoted

quoted

quoted

quoted

quoted

"James" == James Bottomley [off-list ref] writes:

James> On Mon, 2012-09-24 at 17:00 -0400, Jeff Garzik wrote:

quoted

quoted

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.