Profile for SCSI Components Used in High Availability Environments

Gene Milligan Gene_Milligan at notes.seagate.com
Sat Jan 4 21:58:03 PST 1997


* From the SCSI Reflector (scsi at symbios.com), posted by:
* Gene Milligan <Gene_Milligan at notes.seagate.com>
*
For unknown reasons at the last scheduled working group on this item, 
discussion was cutoff and relegated to the reflector. I have not seen any 
discussion on the reflector either and unfortunately was not able to generate 
any until now.

The forest:

 Although not covered by the abstract or the scope, the title clearly indicates 
the purpose of the technical report. However my impression is that rather than 
presenting a clear interoperable profile the technical report is light on 
specific requirements that are not equivocated within the technical report. I 
think it would be informative for the advocates to prepare a bulletized list of 
the profile requirements thought to be included in the technical report which 
are not mandatory SCSI-3 requirements. My impression is that the list would be 
too short to justify someone purchasing the technical report. At the moment I 
think it would be better to use it as the basis for a magazine article.

 The balance of these comments assume that the list is flushed out and the 
technical report actually documents a beneficial profile for interoperability.

The trees: (The reader needs to refer to a copy of X3T10/TBDTR)

1) Although a plea is made to apply the profile where appropriate to other 
interconnects it is highly parallel oriented and the titles should be change to 
Profile for SCSI Components Used in Parallel SCSI High Availability 
Environments.

2) X3T10 should eliminate the negative outlook of the abstract. An acceptable 
version would be "This technical report defines a profile for the use of 
parallel SCSI equipment in environments where high system availability is 
required."

3) Although it may be in a template, the last paragraph of the clause X3's 
Technical Report Series seems inappropriate for the TR and I think should be 
deleted.

4) The foreword states that the traditional use of SCSI is with small desktop 
systems or workstations. I think this statement is wrong with this being the 
traditional use of ATA. I think a more appropriate statement would relate to 
the traditional use of SCSI being with servers and workstations.

5) The second paragraph alleges that SCSI is now seen as an interconnect that 
is suitable on high-end computer systems. In my view SCSI has long been seen as 
an interconnect that is suitable on high-end computer systems.

6)  What are "higher level of requirements" that many SCSI devices already in 
the field do not meet? 

7) In the final sentence of the third paragraph I recommend replacing "so that 
they make implementation choices that" with "to".

8) The start of the  fourth paragraph should be "This".

9) Regarding the fifth paragraph, why did X3T10.1 forward this TR to X3T10 with 
so many TBD's. What was the vote? Why was it within their scope? Why did it 
take them three years to complete? What does "started in 1995Technical Report" 
mean?

10) Assuming the paragraph of comment (9) is spurious, the sentence ahead of 
the X3T10 membership should be changed to "developed" rather than "reviewed".

11) Regarding the introduction, Clause 2 should be changed to "references" 
rather than "normative references".

12) Clause 11 and numerous places should be changed from SCSI-2 nomenclature 
(bus phases) to SCSI-3 nomenclature.

13) As with the abstract, change the scope to "This technical report defines a 
profile for the use of parallel SCSI components in systems where high 
availability is obtained by the use of multiple hosts and multiple devices 
connected by a single SCSI bus." However a word of caution is that rather than 
just a single SCSI bus the profile appears to include a hierarchy of SCSI buses.

14) Move the material contained in the first paragraph and bullets of Clause 2 
which should be references to a new Key Words clause. Having done that then use 
the key words rather than the typically used "must".

15) The last paragraph of Clause 2 should be replaced with a more traditional 
listing of references.

16) The 3.1.1 definition of High Availability SCSI System does not add anything 
to Websters. It seems to leave out the key relationship to a component failure. 
The other 3.1.1 clauses on High Availability have the same problem.

17) In the next to last clause 3.1.1 I think "must" should be replaced with 
"needs to".

18) Regarding the last 3.1.1 did you have anything in mind?

19) Clause 3.2 is not needed as yet.

20) In clause 5 I think "potential failures" to "failures".

21) Is it an intention of the last sentence in the first paragraph and the 
balance of Clause 5 to make mirroring a requirement of the profile has opposed 
to other forms of redundant failure protection?

22) A candidate for the extra last 3.1.1 clause is "host failover" and/or 
"failover" in general.

23) In clause 6 what does "Controller failover is usually implemented inside a 
controller cabinet" mean?

24) What is the difference in a profile between a "critical requirement" and a 
"requirement"?

25) In the fourth paragraph of clause 6 delete "in the case of" and "only".

26) In the next paragraph replace "In the case where" with "If". Delete "Thus". 

27) In the sixth paragraph delete "that must be addressed" or replace it with 
"beyond the scope of this TR". If the last choice is selected, delete the last 
sentence of the paragraph. If not change it to "discussed further".

28) What is "failover of network traffic"?

29) I think the figure titles should be under the figures.

30) Why does the TR differentiate in scope between active bus extenders and 
active terminators?

31) Is "boot software" appropriate terminology?

32) Is "run-time driver" appropriate terminology?

33) How does the exclusion of hot plugging the SCSI bus itself relate to 
terminators and bus extenders?

34) Is the requirement for good design better than forbidding bad design?

35) How would you conclude that an implementation meets the requirement for 
good system-wide responsiveness?

36) There is a generic need to replace forms of "insure" with forms of "ensure".

37) In clause 7 is the requirement to comply with all the optional requirements 
of SCSI-3 or just the mandatory requirements?

38) Does the requirement to comply with the latest revisions imply that field 
retrofits are mandatory? Is the requirement in the second paragraph that 
vendors make verbal statements and should the identification be impacted by 
editorial revisions which have no substantive changes? I thought the author of 
this TR had previously opposed the proposal to have revision information 
available through an interface function on the basis that the information was 
not of value.

39) Why does clause 7 assume SPI revision 15a is the current version of the 
SCSI-3 Parallel Interface with SPI-2 being actively worked? For these systems 
the revisions of the terminator back to allow SCSI-2 active terminators may be 
of keen interest unless the profile bites the bullet and chooses differential - 
not my recommendation.

40) What are the specific additional exclusions and what was the first 
exclusion of SCSI-3 called out by the TR?

41) Regarding 8.1 I don't think SCSI hosts are hot plugged. I think SCSI 
initiators are hot plugged.

42) Rather than testing whether the need for Multi-Host coordination can be 
overemphasized, it would be better to simply state it as a requirement. Even 
better would be to define how it is coordinated. I think the TR is silent on 
whether or not the profile is for non-homogeneous hosts.

43) Regarding 8.2.1 are "Y" cables defined somewhere? 

44) Is the single-connector option the SCA of SPI-2?

45) Why are backpanel designs excluded in view of the SCA popularity?

46) What does the second paragraph of 8.2.1 mean? It seems to me that in 
significant subsystems the use of the "Y" connection is highly problematic for 
stubs.

47) Regarding the fourth paragraph are the dual redundant power supplies really 
independent? I was not aware that storage devices were readily available with 
dual independent power connections.

48) Why does the profile require SCAM? SCAM is certainly not needed with SCA.

49) How does one check compliance with the requirement in 8.2.2 for tests and 
sequences to run correctly on an active SCSI bus?

50) What is a console? What is console firmware?

51) Why are persistent reservations not included in 8.2.2?

52) Why are hosts required to coordinate the mode pages if the device is 
required to not have multiple initiator mode pages? Does SCSI provide a method 
for disabling the normal multiple pages? Why not just require the coordination?

53) Clause 9.1 indicates that the system (host?) should have a means of 
automatic verification of the configuration but does not define a method. Is 
this intended to require a vendor specific method? What is the extent of 
configuration parameters to be automatically determined? Some examples are 
given but the full list is not defined.

54) It also requires that HBA's have a means of not negotiating wide or fast. 
If the devices are wide, should there also be a requirement that they default 
to narrow? Sorry I don't have the time just now to see if SCSI-3 already 
requires such a default and have forgotten if it does. It would seem more 
productive to require that the initiators provide a means for the host to 
control what is negotiated.

55) The profile rather than making connection version required states a strong 
preference for the "Y" connection. Clause 9.2 gives an unexplained reference to 
SPI Note 3. That note gives a strong recommendation for the non-"Y" connection. 
Profiles normally are generated to remove such mixed signals, not amplify them.

56) Does the requirement of 9.2.1 require that a terminator dangle in the 
breeze on the end of the last cable segment as opposed to having a dedicated 
mounting place in an enclosure?

57) Clause 9.2.2 defines a less desirable option. As a profile why not rule out 
the less desirable option? However X3T10 should decide if the author has the 
cases reversed. Not the aggregate X3T10 but the host manufacturers (not 
initiator) and the system integrators to be sure we are not seeing the 
preference of one system manufacturer (even if it is one I admire).

58) Why do the less desirable options only have to meet the requirements of the 
shielded connector clause of SPI?

59) Regardless of 9.2.3 it is not factual that "... in single user environments 
only, the physical position of the SCSI bus terminators is not important."

60) Will it be clear what "All other configurations are unsuitable for use in 
High Availability configurations must be avoided" refers to? For example, does 
this mean that Ultra 2 configurations should be avoided or does it mean that 
SSA configurations should be avoided?

61) While 9.2.4.3 is presently TBD, it should be deleted for now since LVD Case 
4 hot plugging has not yet been sanctioned although there are glimmers in the 
eyes.

62) What is the purpose of 9.2.4.4 TBD?

63) In clause 10.1 there is a requirement to reapply power to a hot plugged 
device. Why? I thought hot plugging meant that power was applied during removal 
and insertion.

64) It also casually throws in staggered pin lengths. The only standard for 
this is SCA. Is this a recommendation that vendor unique pin lengths be used?

65) How is compliance for "well-behaved" tested?

66) Devices can only be tolerant of specified electrostatic discharge levels 
not opened ended levels. Even if the device is tolerant the bus is not. SCA 
addressed this issue but it is not clear what the TR requirement is.

67) In one of the more perplexing issues clause 10.2.1 requires allows 
switchable terminators to be used and requires that optional internal 
terminators not be used. The most prevalent, if not the only application of 
switchable terminators is for optional internal terminators.

68) In 10.2.2 what are the requirements for "well-behaved"?

69) Why is the mandatory SCSI requirement for drivers to be in the high 
impedance state during power-up cycles repeated in the profile. Does this mean 
than mandatory SCSI requirements not mentioned in the profile need not be 
complied with? Why is the requirement stated twice in this clause?

70) What is the unit attention flag?

71) In spite of the earlier requirement for SCAM, clause 11.2.1 requires that 
devices implement fixed IDs.

72) Regarding 11.2.2 in SCSI-3 terminology what are general resets?

73) What does coordinate between themselves mean?

74) Regarding 11.2.3 what does "bus event" mean?

75) This clause requires that renegotiation be performed. An earlier clause 
advocated having negotiation disabled.

76) Why should bus options be negotiated before INQUIRY which can provide 
information on what should be negotiated?

77) An earlier clause apparently required a mode for narrow asynchronous only. 
This clause requires a mode for narrow synchronous only. It claims that narrow 
synchronous will work with invalid bus configurations.

78) What is console code? Is it similar to console microcode?

79) This clause requires that initiators assume that the device has been reset 
since the last command. Does this mean that the initiator should check the mode 
pages and assume that the queue was cleared before each command?

80) Does 11.2.4 require that all messages be implemented including those that 
the original proposers have long since abandoned?

81) But the next paragraph indicates that optional messages need not be 
implemented. Which is the overriding requirement?

82) There is at least one word missing from the last sentence of the third 
paragraph of 11.2.4.

83) Several places "with sense key" should be changed to "with a sense key".

84) The requirement for "parity" checking should be changed to "SCSI bus 
parity".

85) Clause 11.2.6 requires targets to be busy until they have flushed the cache 
after an Abort message. Why is this required if resources are available?

86) Regarding 12.1 it is nice that profile does not require that targets 
improperly handle bus resets or reservations.

87) How can a newly added host predict vendor unique defaults which seem to be 
equivalent to prior setup information?

88) How does a target manufacturer test for properly supporting simultaneous 
hosts? What are simultaneous hosts?

89) Why is there a requirement for targets to accept commands at any bus ID? 
Will this not cause contention on the part of targets?

90) This clause requires mode pages, or is that not sense data, to be on a per 
initiator basis but an earlier requirement recommended that it not be.

91) This clause allows hosts not to use reservations. I think an earlier clause 
require that they do.

92) What constitutes handling tagged commands in a timely manner?

93) The requirements of the last paragraph of 12.2.1, the first two & fourth 
paragraphs of 12.2.2, and the second paragraph of 12.2.3 to be normal mandatory 
requirements of SCSI-3.

94) What does the last paragraph of 12.2.2 mean?

95) Clause 12.2.3 introduces the concept of logical units being optional. I 
thought all targets had to have a minimum of one logical unit.

96) What is Bad Block Replacement (BBR) in SCSI-3 terminology?

97) What is "wastage of revectoring resources"?

98) This clause refers to an ASC/ASCQ as SELECT or RESET FAILURE which in 
SCSI-3 is SELECT or RESELECT FAILURE. 

99) SIP requires that MESSAGE REJECT be an aspect of wide negotiations, the TR 
forbids the use. This seems to be a violation of SCSI.

100) In 12.2.5 what does "allocate devices" mean?

101) Why does this clause not deal with persistent reservations?

102) What is Remove? This may violate persistent reservations. Is the violation 
intended?

103) The RESERVATION CONFLICT bullet should have been part of the text.

104) Isn't the processing of RELEASE a violation of SCSI?

105) How would a logical unit discover that it's requirements are given in 13.1 
Initiator Device Requirements and how would the implementor know if the 
indefinite requirement for adequate queue command space had been met?

106) How does an internal HBA ensure that the "particularly important" 
requirement of 13.2.2 for external bus termination requirements are met beyond 
not enabling the internal terminator?

107) What does "meet all the requirements at all times" mean?

108) Why should the TR allege that boot-time discrepancies (whatever they may 
be) from normal SCSI usage are common with single-user systems?

109) What is a console halt command?

110) What is the stall state?

111) This initiator requirements clause requires that all mandatory Processor 
Device Type command be supported. But it is not clear if they need to be 
supported as an initiator, as a target, or as both.

112) What does "select the system as target" mean?

113) What "situation" is being referred to?

114) Which adapters since Seagate went out of the single user HBA business have 
little intelligence in them?

115) In 13.2.3 what does "and can be require lengthy recovery activity" mean?

116) What is "mainline driver code"? Is this drug terminology?

117) How do you "coax the target"?

118) Clause 13.2.3 has several paragraphs which are repeats of prior 
requirements.

119) The last requirement I think has previously stated as 60 seconds rather 
than 250 milliseconds.

120) Does the requirement of 13.2.4 require that a queue full error be detected 
before the queue is full?

121) How do you reserve tag queue elements? What are tag queue elements?

122) Is 14.1 forthcoming or should it be eliminated?

123) Is 14.2 forthcoming or should it be eliminated?

124) Is 14.3 forthcoming or should it be eliminated?

125) I think clause 15 should be deleted.

 I understand this TR has been scheduled for an editorial review on Friday of 
the X3T10 week. It seemed premature for an editorial review before doing a 
technical review in the WG (scheduled but rejected) but I will bring my marked 
up copy to the editorial review. I assume it will not also be dismissed out of 
hand.

Gene 

*
* For SCSI Reflector information, send a message with
* 'info scsi' (no quotes) in the message body to majordomo at symbios.com




More information about the T10 mailing list