From: Hannes Reinecke <hare@suse.de>
To: "Jörn Engel" <joern@logfs.org>
Cc: James Bottomley <jbottomley@parallels.com>,
"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
Ewan Milne <emilne@redhat.com>,
Ren Mingxin <renmx@cn.fujitsu.com>,
Bart van Assche <bvanassche@acm.org>
Subject: Re: [PATCHv2 0/7] Limit overall SCSI EH runtime
Date: Tue, 02 Jul 2013 07:48:08 +0200 [thread overview]
Message-ID: <51D26998.2050506@suse.de> (raw)
In-Reply-To: <20130701205546.GB10645@logfs.org>
On 07/01/2013 10:55 PM, Jörn Engel wrote:
> On Mon, 1 July 2013 19:23:25 +0000, James Bottomley wrote:
>> On Mon, 2013-07-01 at 13:44 -0400, Jörn Engel wrote:
>>> If a single device is bad, don't ever do a host
>>> reset.
>>
>> This isn't a tenable position. Sometimes a device looks bad because the
>> host state for it has gone insane. At that point, the only safe action
>> is a reset of the host to sane state.
>>
>> I could be persuaded that you should never do the transport equivalent
>> of a bus reset (on non-SPI transports, at least), which is actually hard
>> to do on some of the modern transports, but I don't think you can get
>> away without having a host reset in the eh arsenal.
>
> Fair enough. Hardware being hardware and hardware bugs being hard to
> fix, I see your point.
>
> However, we shouldn't screw the poor user who has paid a premium for a
> second HBA to get some redundancy and reset both of them at the same
> time. That would, you know, defeat the redundancy. ;)
>
Which would arguably a setup issue.
We've had SAN issues where the HBA lost track of the remote port
state (RSCNs being eaten by the switch firmware), so the only chance
of recovery was indeed a host reset.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
hare@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2013-07-02 5:48 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-01 6:50 [PATCHv2 0/7] Limit overall SCSI EH runtime Hannes Reinecke
2013-07-01 6:50 ` [PATCH 1/7] dpt_i2o: Remove DPTI_STATE_IOCTL Hannes Reinecke
2013-07-01 6:50 ` [PATCH 2/7] dpt_i2o: return SCSI_MLQUEUE_HOST_BUSY when in reset Hannes Reinecke
2013-07-01 6:50 ` [PATCH 3/7] advansys: Remove 'last_reset' references Hannes Reinecke
2013-07-01 6:50 ` [PATCH 4/7] tmscsim: Move 'last_reset' into host structure Hannes Reinecke
2013-07-01 6:50 ` [PATCH 5/7] dc395: Move 'last_reset' into internal " Hannes Reinecke
2013-07-01 6:50 ` [PATCH 6/7] scsi: remove check for 'resetting' Hannes Reinecke
2013-07-01 6:50 ` [PATCH 7/7] scsi: Add 'eh_deadline' to limit SCSI EH runtime Hannes Reinecke
2013-09-20 7:48 ` Ren Mingxin
2013-10-16 19:22 ` James Bottomley
2013-10-17 14:27 ` Ewan Milne
2013-10-23 9:25 ` Hannes Reinecke
2013-10-23 7:46 ` James Bottomley
2013-10-23 9:49 ` Hannes Reinecke
2013-07-01 17:44 ` [PATCHv2 0/7] Limit overall " Jörn Engel
2013-07-01 19:23 ` James Bottomley
2013-07-01 20:55 ` Jörn Engel
2013-07-02 5:48 ` Hannes Reinecke [this message]
2013-07-02 6:37 ` James Bottomley
2013-07-02 14:58 ` Jörn Engel
2013-07-02 16:33 ` James Bottomley
2013-07-02 15:50 ` Jörn Engel
2013-07-10 20:35 ` Ewan Milne
2013-07-12 5:54 ` Ren Mingxin
2013-07-12 13:30 ` Ewan Milne
2013-07-15 10:33 ` Ren Mingxin
2013-07-26 9:52 ` Ren Mingxin
2013-08-07 6:43 ` Ren Mingxin
2013-08-29 13:06 ` Hannes Reinecke
2013-09-24 20:51 ` Ric Wheeler
2013-09-25 5:48 ` Hannes Reinecke
2013-10-02 16:21 ` Hannes Reinecke
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=51D26998.2050506@suse.de \
--to=hare@suse.de \
--cc=bvanassche@acm.org \
--cc=emilne@redhat.com \
--cc=jbottomley@parallels.com \
--cc=joern@logfs.org \
--cc=linux-scsi@vger.kernel.org \
--cc=renmx@cn.fujitsu.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.