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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAA9_cmcB1UrvcEM+VQ57nmi2JgUQgXB4+Jj7=Je-5ZKp7k0t1w@mail.gmail.com>
Date:	Fri, 28 Sep 2012 11:39:34 -0700
From:	Dan Williams <djbw@...com>
To:	"Martin K. Petersen" <martin.petersen@...cle.com>
Cc:	James Bottomley <James.Bottomley@...senpartnership.com>,
	Jeff Garzik <jeff@...zik.org>, linux-scsi@...r.kernel.org,
	LKML <linux-kernel@...r.kernel.org>,
	"dave.jiang" <dave.jiang@...el.com>,
	"Skirvin, Jeffrey D" <jeffrey.d.skirvin@...el.com>
Subject: Re: [SCSI PATCH] sd: max-retries becomes configurable

On Wed, Sep 26, 2012 at 7:20 PM, Martin K. Petersen
<martin.petersen@...cle.com> wrote:
>>>>>> "James" == James Bottomley <James.Bottomley@...senPartnership.com> 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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/