X3T9.2/87-167 Rev 1 To: X3T9.2 Committee (SCSI) From: Gerry Houlder MPI/CDC Subject: Suggested changes to MODE SELECT command Revision 1: Rev. 0 referenced Rev. 2 of the SCSI-2 draft and now that Rev. 3 is out, the memo is being rewritten to reference Rev. 3. MODE SELECT was completely reorganized in Rev. 3. Also, some items in the original memo are already fixed, so they were deleted. This is a list of recommended MODE SELECT command changes, most of which involve clarifying descriptions of mode parameters. page 7-40, add an implementors note at bottom of page, after the block length description: "IMPLEMENTORS NOTE: For direct access devices, the block length affects the optimum values (the values that achieve best performance) for the Sectors per Track, Bytes per Physical Sector, Track Skew Factor, and Cylinder Skew Factor parameters in page 3. Thus, when a MODE SELECT command changes the block length, a subsequent MODE SENSE command returning page 3 current values may have new values for these four parameters even though they weren't specifically changed in the MODE SELECT." This note allows the target to do 'implied' changes of some parameters when the block length is changed. If the initiator sends new values in page 3 when it changes the block size, and the new values are not optimum, the resulting performance may not be satisfactory. If the initiator only sends the new block descriptor (and not any page 3 values), the target can always use the values it thinks are best and save the initiator from having to figure out what the best values are. Now, if the initiator thinks the new values returned in MODE SENSE aren't really optimum for his system, he can send another MODE SELECT with his preferred page 3 values and the target must accept them, overriding the previous 'best' values. Embedded controllers will especially want to do this and the standard should allow it. page 8-18, second paragraph from bottom: the first sentence says that "..the failing data block, whether corrected or not,.." is returned. I believe the context of 'failing' means 'uncor- rectable within the recovery limits specified', which means that such a block is never corrected. The intent of CCS was that all corrected data blocks be returned to the initiator regardless of the state of this bit, but the phrase "whether corrected or not" leaves a doubt in the reader's mind about that. The paragraph should be changed to read: "A Transfer Block (TB) bit of one indicates that any data block that is uncorrectable within the recovery limits specified shall be transferred to the initiator before CHECK CONDITION status is returned. A TB bit of zero indicates that such a data block shall not be transferred to the initiator. Data blocks that can be corrected within the recovery limits are always transferred, regardless of the value of this bit." page 8-20, EER bit description and DTE bit description have had wording deleted that warns of certain bit combinations being invalid. I believe these warnings must be reinstated, because there isn't anyplace else that explains WHY those combinations are invalid. I suggest the following changes: The first paragraph of table starts with "1 - - -". Change it to "1 - - 0". Add a paragraph under this paragraph that reads: "1 - - 1 Invalid combination. When correction is disabled, expedient error recovery isn't possible." The fourth paragraph of the table starts with "- 0 - -". Change it to "- 0 0 -". Add a paragraph under this paragraph that reads: "- 0 1 - Invalid combination. When reporting of recovered errors is disabled, stopping data transfer on re- covered errors isn't allowed." The fifth paragraph of the table starts with "- - 1 -". Change it to "- 1 1 -". The seventh paragraph starts with "- - - 1". Change it to "0 - - 1". page 8-27, 2nd paragraph: the values of the PER and DTE bits do not affect the disabling of correction and retries, only reporting. The last part of that sentence should read "..should set the EER bit to zero, the DCR bit to one,..". I have noticed 3 different ways that 'parameter rounding' is referenced. See page 8-27, last paragraph; page 8-28, first paragraph; page 8-28, 3rd paragraph; page 8-34, 2nd paragraph. We need a consistent way of referencing parameter rounding. I prefer adding a sentence to each parameter description (where rounding is allowed) as follows: "The target may round this value up (down) as described in 6.5.4.". Each reference should use either up or down as deemed appropriate. page 8-34, 3rd paragraph from bottom: The sectors per track description is ambiguous because of the word 'used'. Are spare sectors really 'used'? Are they to be counted here? A reference to 'variable sectors per track' devices is also needed. I want to change the paragraph to read: "The Sectors per Track field specifies the number of physical sectors included within each track. This number includes any alternate sectors the target may allocate. A value of zero during MODE SELECT indicates that the target shall use its optimum number of sectors per track. For devices with a variable number of sectors per track, the value in MODE SELECT must be zero and the value reported in MODE SENSE is the average number of sectors per track." page 8-34, 2nd paragraph from bottom: The last sentence should be defined more exactly so the initiator knows what to expect. Change it to read: "A value of zero indicates that the target is to use its optimum value of Data Bytes per Physical Sector for the requested logical block size." page 8-35, first and 2nd paragraphs: skewing a constant number of "physical" sectors between the "last logical block" of one track and the "first logical block" of the next track is difficult when using a spare sector per track scheme. Some spares will be assigned as logical blocks but most will not. If a block is reassigned, must the next track (or tracks) be rewritten to keep the skew from being reduced by one sector? It is also unfortunate that the skew factor is so dependent on block size. To maintain the same skew when the block size is changed requires this number to be recalculated too. How about changing the skews to a minimum number of microseconds delay, which the target can round up to its best capable value? If a 100 microsecond increment were used (like the time limit fields of page 2), one byte would handle the needed range of values. The disadvantage of this idea is incompatibility with CCS. Do the advantages outweigh this? page 8-36, Number of Cylinders field description: the words "used for data storage" doesn't clarify whether spare cylinders are included. Are spare cylinders used for data storage? Are they used for anything but data storage? Most vendors don't include spare cylinders in the number reported here, so the wording should be clarified to say that. Change it to read: "The Number of Cylinders field defines the number of physical cylinders included in the user addressable address space." page 8-36, Number of Heads field description: same comment as preceding paragraph, plus we don't want people to think that heads combining data and servo shouldn't be counted. Change it to read: "The Number of Heads field defines the physical number of heads included in the user addressable address space. Heads used only for servo information are excluded."