From: "Martin K. Petersen" <martin.petersen@oracle.com>
To: Baruch Even <baruch@ev-en.org>
Cc: emilne@redhat.com,
"Martin K. Petersen" <martin.petersen@oracle.com>,
linux-scsi <linux-scsi@vger.kernel.org>,
Hannes Reinecke <hare@suse.de>,
michaelc@cs.wisc.edu
Subject: Re: [PATCH] scsi: Allow error handling timeout to be specified
Date: Fri, 10 May 2013 10:53:41 -0400 [thread overview]
Message-ID: <yq1k3n6dgy2.fsf@sermon.lab.mkp.net> (raw)
In-Reply-To: <CAC9+anJ9Y-SnCOK6EOCavTNJwx=xhAbL_X__MsEsL7DroawaJg@mail.gmail.com> (Baruch Even's message of "Fri, 10 May 2013 16:20:52 +0300")
>>>>> "Baruch" == Baruch Even <baruch@ev-en.org> writes:
Baruch> Actually reducing the timeouts is probably not a good approach
Baruch> since it will cause the host to take a more radical approach
Baruch> without waiting sufficiently for a potential recovery.
Reducing the eh timeout is a requirement in many clustered setups. We've
been shipping a predecessor to this patch in our kernels for a long
time.
Baruch> In addition the more radical error handlings such as host reset
Baruch> will destroy other paths for completely unrelated devices/links,
Baruch> from my experience a host reset is usually not required and the
Baruch> Linux kernel currently reaches to this big hammer too fast.
I'm also working on a patch to add some heuristics to avoid the HBA and
bus resets if I/O is completing successfully on other attached
targets. But that's an orthogonal issue.
--
Martin K. Petersen Oracle Linux Engineering
next prev parent reply other threads:[~2013-05-10 14:54 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-10 3:11 [PATCH] scsi: Allow error handling timeout to be specified Martin K. Petersen
2013-05-10 6:23 ` Bart Van Assche
2013-05-10 14:36 ` Martin K. Petersen
2013-05-10 12:43 ` Ewan Milne
2013-05-10 12:55 ` Hannes Reinecke
2013-05-10 13:09 ` Bryn M. Reeves
2013-05-10 13:22 ` Baruch Even
2013-05-10 14:01 ` Ewan Milne
2013-05-10 14:24 ` Hannes Reinecke
2013-05-10 14:31 ` Bryn M. Reeves
2013-05-10 16:59 ` Ewan Milne
2013-05-13 15:16 ` Elliott, Robert (Server Storage)
2013-05-10 17:51 ` Baruch Even
2013-05-10 20:18 ` Hannes Reinecke
2013-05-10 19:27 ` Baruch Even
2013-05-13 5:46 ` Hannes Reinecke
2013-05-13 14:40 ` Jeremy Linton
2013-05-13 15:03 ` Hannes Reinecke
2013-05-13 15:58 ` Jeremy Linton
2013-05-13 16:50 ` Baruch Even
2013-05-13 20:29 ` Martin K. Petersen
2013-05-13 21:01 ` Jeremy Linton
2013-05-14 22:21 ` Martin K. Petersen
[not found] ` <CAC9+anJ9Y-SnCOK6EOCavTNJwx=xhAbL_X__MsEsL7DroawaJg@mail.gmail.com>
2013-05-10 14:53 ` Martin K. Petersen [this message]
2013-05-10 15:27 ` Martin K. Petersen
2013-05-10 17:55 ` Baruch Even
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=yq1k3n6dgy2.fsf@sermon.lab.mkp.net \
--to=martin.petersen@oracle.com \
--cc=baruch@ev-en.org \
--cc=emilne@redhat.com \
--cc=hare@suse.de \
--cc=linux-scsi@vger.kernel.org \
--cc=michaelc@cs.wisc.edu \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox