Does TST == 001b break initiator software?
ROWEBER at acm.org
ROWEBER at acm.org
Sat Apr 4 06:37:06 PST 1998
* From the T10 (formerly SCSI) Reflector (t10 at symbios.com), posted by:
* ROWEBER at acm.org
I support Gerry Houlder's position, 110%. (Gerry, I couldn't have
said it better.)
I should also note that all today's standard implementations of
multi-initiator operating system software are based on TST=000b.
(Until last month, all other implementations were, by definition
vendor unique.) As I noted previously, the current implementations
should take the approval of 97-225 as a call to update their mode
page checking code. If such systems clearly depend on the TST=000b
behavior, they had better start verifying that it is really there.
As for implementations using TST=001b, they are new implementations,
at least with respect to what is specified in the standards. Since
they are new implementations, they should have no problem coping with
the fact that ABORT TASK SET is the same as CLEAR TASK SET. Just as
the standard makes it pretty clear that a READ command will transfer
data to the host, the standard can (should) made it clear that ABORT
TASK SET is the same as CLEAR TASK SET, when TST=001b. It's all a
part of incorporating 97-225 in the draft standards.
(Peter, you are right, we have been viewing the situation from
different perspectives. I hope the two paragraphs above clarify mine.)
To save Gene from having to correct me, I'll state here that people
say that somewhere out there is at least one system implementation
that depends on the TST=001b behavior for some type of shared disk
However, based on my experience, it is not possible to develop a
cluster-like mass storage data sharing multi-initiator implementation
without benefit of either TST=000b support, or Persistent Reservations
support, OR BOTH. One cannot simultaneously share the data on a disk
with another initiator and pretend that the other initiator is not
there (which is the essence of TST=001b behavior). One can share the
storage capacity (e.g., partitioning) blindly, but one cannot share
the data contained within the storage capacity without some cross-
initiator help from the storage device.
In this regard, I agree with Larry Chen -- specifically -- multi-
initiator support is a non-goal for device implementations that
support only TST=001b. Certainly, those multi-initiator implementa-
tions known to me will not work when TST=001b. I strongly suspect
(but cannot prove) that this applies to Windows NT Wolfpack too. The
only exception would be if a multi-initiator implementation could be
achieved using only Persistent Reservations and having no dependence
on the TST setting. Bob Snively may have considered this possibility
in sufficient detail to comment, I have not.
This leads to one final point; when only one initiator is present,
the behavior of ABORT TASK SET is identical to that of CLEAR TASK SET
regardless of what code the SCSI device executes in order to perform
them. Once again Gerry Houlder's comments opposing the obsolesce of
CLEAR TASK SET ring clear and true.
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at symbios.com
More information about the T10