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 
support.

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.

Thanks.

Ralph...
*
* 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 mailing list