From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: "Martin K. Petersen" <martin.petersen@oracle.com>
Cc: Jeff Garzik <jeff@garzik.org>,
linux-scsi@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>
Subject: Re: [SCSI PATCH] sd: max-retries becomes configurable
Date: Thu, 27 Sep 2012 08:45:24 +0400 [thread overview]
Message-ID: <1348721124.2509.1.camel@dabdike> (raw)
In-Reply-To: <yq1y5jw9pfd.fsf@sermon.lab.mkp.net>
On Wed, 2012-09-26 at 22:20 -0400, Martin K. Petersen wrote:
> >>>>> "James" == James Bottomley <James.Bottomley@HansenPartnership.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?
request_queue makes more sense to me because there was once a plan to
move all our timeout processing to block. I think it got stalled
somewhere, but this would act as a reminder.
James
next prev parent reply other threads:[~2012-09-27 4:45 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-24 21:00 [SCSI PATCH] sd: max-retries becomes configurable Jeff Garzik
2012-09-25 4:06 ` James Bottomley
2012-09-25 5:21 ` Jeff Garzik
2012-09-25 10:38 ` James Bottomley
2012-09-27 5:04 ` Jeff Garzik
2012-10-01 7:43 ` Ric Wheeler
2012-09-27 2:20 ` Martin K. Petersen
2012-09-27 4:45 ` James Bottomley [this message]
2012-09-28 18:39 ` Dan Williams
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1348721124.2509.1.camel@dabdike \
--to=james.bottomley@hansenpartnership.com \
--cc=jeff@garzik.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.