From: Jeremy Linton <jlinton@tributary.com>
To: Hannes Reinecke <hare@suse.de>
Cc: Baruch Even <baruch@ev-en.org>, emilne <emilne@redhat.com>,
"Martin K. Petersen" <martin.petersen@oracle.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: Mon, 13 May 2013 10:58:40 -0500 [thread overview]
Message-ID: <51910DB0.70009@tributary.com> (raw)
In-Reply-To: <519100A5.2060509@suse.de>
On 5/13/2013 10:03 AM, Hannes Reinecke wrote:
> The other LUNs haven't reported an error. But how do you know whether they
> are still okay? The other LUNs might simply be idle, and no commands have
> been send to them.
Well, how about generating std inquiry against them if they are idle and the
given HBA has a device in error state? Then you can make a rough approximation
of what has failed, and escalate the error handling if all the devices at a
particular level have failed.
The midlayer may not even need to send the inquiries. If the individual
device drivers (sd/st/etc) are responsible for monitoring and error recovery
then they can be tasked with determining device availability as well. I think
this solves other problems too. For example, the use of TUR in the midlayer,
is a problem because it doesn't have enough knowledge about the possible check
conditions being returned to act on them appropriately.
next prev parent reply other threads:[~2013-05-13 15:58 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 [this message]
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
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=51910DB0.70009@tributary.com \
--to=jlinton@tributary.com \
--cc=baruch@ev-en.org \
--cc=emilne@redhat.com \
--cc=hare@suse.de \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--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