From: Jeremy Linton <jlinton@tributary.com>
To: Hannes Reinecke <hare@suse.de>, Linux Scsi <linux-scsi@vger.kernel.org>
Subject: Re: Error handling on FC devices
Date: Mon, 3 Dec 2012 11:19:54 -0600 [thread overview]
Message-ID: <50BCDF3A.6040608@tributary.com> (raw)
In-Reply-To: <50BC517E.4090208@suse.de>
On 12/3/2012 1:15 AM, Hannes Reinecke wrote:
> Well, looking at QLogic and Emulex both emulate a bus reset with a loop
> over each target and invoke a target reset there. I somewhat fail to see
> the rationale behind it, other than emulating the bus reset behaviour on
> SPI.
It is actually a _VERY_ bad idea in multiple initiator tape environments with
switched fibre where the resets can affect devices that are visible but not
owned/controlled by the machine broadcasting resets. Many tape environments
operate this way as the physical drives are assigned dynamically to initiators
as necessary. In some cases (ACSLS) the machine/OS/backup applications aren't
even homogenous.
The rewind and loss of PR/etc, which if not handled properly by all the other
machines on the SAN can be quite disastrous.
Its also somewhat problematic even in single initiator environments as the
reset can affect devices not having problems, and the 6/2900's can get eaten
by the logic attempting the reset, which leaves the user of a functional
device in the dark that it was reset/rewound.
I was told last time I brought this up, that it was impossible for a single
device's failure to result in that bus reset path being called. Which was
patently false as the problem was only tracked down because of a repeatable
case of a single device failing in a manner which triggered progressively more
aggressive recovery culminating in the bus-reset being called.
The result was a single device cascading a failure to a bunch of functional
devices and interrupting their operation.
next prev parent reply other threads:[~2012-12-03 17:25 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-19 12:41 Error handling on FC devices Hannes Reinecke
2012-11-26 22:32 ` James Smart
2012-11-27 20:03 ` Ewan Milne
2012-11-27 20:29 ` Elliott, Robert (Server Storage)
2012-11-28 7:09 ` Hannes Reinecke
2012-11-29 16:02 ` James Smart
2012-11-30 11:44 ` Hannes Reinecke
2012-11-30 16:54 ` Mike Christie
2012-12-03 7:15 ` Hannes Reinecke
2012-12-03 17:19 ` Jeremy Linton [this message]
2012-12-03 22:52 ` Elliott, Robert (Server Storage)
2012-12-04 15:56 ` Kipp Aldrich
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=50BCDF3A.6040608@tributary.com \
--to=jlinton@tributary.com \
--cc=hare@suse.de \
--cc=linux-scsi@vger.kernel.org \
/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.