Douglas Gilbert wrote:
It looks like "target reset" is being phased out of SCSI
terminology and being partially replaced by "hard reset".
Well, there's still an "I_T Nexus Reset" within the TMF area, which FCP-4
provides no mapping for, but does define how to create a I_T Nexus loss event.
Headache is there's history... SPI BDRs did full target resets and killed i/o
for all initiators. Target Reset and FCP-2 gave same kind of semantic. FCP-3
and later tried to make initiators better citizens and isolate reset semantics
if possible. Unfortunately, there's lots of users that equate FC to SCSI, SCSI
to SPI, and assume SPI-like semantics. So changing things just to be
standard-compliant always seems to upset someone (and it's usually the most
critical someone).
The third paragraph in the introduction of draft SAM-5
(sam5r02.pdf section 1.1) states:
"The following concepts from previous versions of this
standard are made obsolete by this standard:
a) support for the SPI-5 SCSI transport protocol;
b) Contingent Allegiance;
c) the TARGET RESET task management function;
d) basic task management model;
e) untagged tasks; and
f) linked command function."
The TARGET RESET task management function last appeared
in SAM-2 (ANSI INCITS 366-2003).
A "hard reset" is associated with a power cycle at an
initiator, target or somewhere in between. There is no
SCSI task management function to generate a hard reset.
Some transports have the ability to generate hard resets
via non-SCSI protocols. For example in SAS a target can
be reset with a SMP PHY CONTROL request to an expander
phy attached to a phy on that target. SAS also has a lower
order "link reset" which is invisible at the SCSI protocol
level.
So is there a "hard reset" hook somewhere in FCP-3 ?
Only mapping in FCP-4 is Loop-based. Nothing for non-Loop.
All other events correspond to I_T Nexus Loss and center around login/logout.
For the target_reset entry point, I assume generating something for an I_T
Nexus Loss should be fine. However, it goes against those SPI-isms mentioned
above and can also be a real pain for the driver (discovery sucks). Given all
the history, the OEM test scripts, and bars we've passed to date, I'm very
hesitant to move away from Target Reset.
If we're really going to solve it, it probably requires more than the simple
heirarchial device/tgt/bus/adapter reset escalation entry points (ex: does bus
reset hard-reset all targets, or just terminate local I_T nexus related ios ?)
- and another can of worms.
-- james s
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
