From: "Martin K. Petersen" <martin.petersen@oracle.com>
To: Jeremy Linton <jlinton@tributary.com>
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>,
Hannes Reinecke <hare@suse.de>, Baruch Even <baruch@ev-en.org>,
emilne <emilne@redhat.com>,
linux-scsi <linux-scsi@vger.kernel.org>,
michaelc <michaelc@cs.wisc.edu>
Subject: Re: [PATCH] scsi: Allow error handling timeout to be specified
Date: Tue, 14 May 2013 18:21:15 -0400 [thread overview]
Message-ID: <yq138tp9p9g.fsf@sermon.lab.mkp.net> (raw)
In-Reply-To: <519154AA.5010500@tributary.com> (Jeremy Linton's message of "Mon, 13 May 2013 16:01:30 -0500")
>>>>> "Jeremy" == Jeremy Linton <jlinton@tributary.com> writes:
>> others. We see cases fairly often where a misbehaving target has
>> confused the HBA enough that we can not bring the device back without
>> doing an HBA firmware reset. Despite I/O completing successfully on
>> other targets connected to the same HBA.
Jeremy> This would seem to indicate a HBA/driver bug...
Yep. It's not just targets that go bad!
Jeremy> Except that I've seen the linux error recovery cause more
Jeremy> problems than it solves on a fairly regular basis. I would
Jeremy> rather have a solution designed to isolate failures, than one
Jeremy> that makes a lot of mistakes and causes further problems
Jeremy> (sometimes with other machines). I'm pretty convinced that
Jeremy> attempting everything possible to recover a device when the
Jeremy> underlying problem is unknown is a bad strategy.
There is no one size that fits all. Which is why we're taking steps to
make the error recovery parameters tweakable.
--
Martin K. Petersen Oracle Linux Engineering
next prev parent reply other threads:[~2013-05-14 22:21 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 [this message]
[not found] ` <CAC9+anJ9Y-SnCOK6EOCavTNJwx=xhAbL_X__MsEsL7DroawaJg@mail.gmail.com>
2013-05-10 14:53 ` Martin K. Petersen
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=yq138tp9p9g.fsf@sermon.lab.mkp.net \
--to=martin.petersen@oracle.com \
--cc=baruch@ev-en.org \
--cc=emilne@redhat.com \
--cc=hare@suse.de \
--cc=jlinton@tributary.com \
--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