X3T9.2/87-167 Sept. 16, 1987 To: John Lohmeyer, X3T9.2 Committee (SCSI) chairman From: Gerry Houlder MPI/CDC Subject: Suggested Changes to MODE SELECT command This is a list of recommended changes to the MODE SELECT command that are mostly editorial in nature. If you agree, John, these changes could be made with little or no discussion in Plenary or Working Group meetings. Here goes: page 8-18, 2nd paragraph, second line - change the word "effect" to "affect". page 8-22, after the block length field sentence - This item will cause some technical discussion, but I would like to see an implementor's note here, as follows: "Implementors Note: The chosen logical block size can affect the optimum value (that achieves best performance) for the Sectors per Track field, Data Bytes per Physical Sector field, Track Skew Factor field, and Cylinder Skew Factor field. When an initiator intends to reformat a logical unit to a new logical block size, it should not send the old values for these parameters if page 3 is also sent. The initiator should either: 1) not include any page 3 parameters with the MODE SELECT command that changes the logical block size and use the values determined by the target for the following FORMAT command, or 2) after the MODE SELECT, send a MODE SENSE command to read the current values of page 3 to see if the values have changed (due to the logical block size change). If they have, the initiator should use these new values as the base to add its desired values to. The new page 3 can be sent in another MODE SELECT command before the FORMAT command is sent." This note tries to address the issue of "implied" mode parameter changes. When a new logical block size is sent, a good target will try to use the best possible values for Sectors per Track, Track Skew, etc. When the initiator doesn't send these other parmaeters the target should use its best values and the current values should be updated accordingly so the initiator knows what is going on. If the initiator wants to change other page 3 mode parameters (e. g., spare sectors per zone), it must be careful not to defeat the best value implicitly set by the target. It must read the "new" current values (after the implicitly changed parameters are updated), change the desired parameter, and send the entire page back again in another MODE SELECT command. The description of the "current" mode values (described only in MODE SENSE command) should be updated to allow implied changes as well as parameter rounding (which is another form of implied change). Perhaps the rules of how the current values are created and changed should be described in MODE SELECT, and the MODE SENSE command should use a reference to that description in its "Current Values" section. page 8-24, 5th paragraph, second line - delete the phrase ", whether corrected or not," at the start of this line. For this description, a "failing data block" is always uncorrected although it may be correctable if, for instance, more retrys are allowed or ECC correction is allowed. To reduce confusion, any reference to the fact that a failing data block may already be corrected should be deleted. If it were already corrected, it wouldn't be a "failing" data block! page 8-27, table 8-16, 1st and 5th descriptions - Wording indicating that certain bit combinations are illegal has been deleted. I believe these words must be restored so that something explains why those combinations are illegal. Table 8- 17 indicates that the combinations are illegal but not why. I think we owe future readers some kind of explanation. A standard and consistent way of stating which parameters may be rounded is needed. We now have 3 different wordings embracing 2 different concepts of how to do this. page 8-33, paragraphs 1 and 2 show the first concept ("..shall round to the nearest whole buffer block and terminate the command as described in section 6."). The second version of that wording is on page 8-34, paragraphs 1 and 2 (".. may round this value as described in 6."). The third version (and a different concept) is on page 8- 36, paragraph 2. This paragraph states up front that four particular fields in this page "..may round these fields to acceptable values as described in 6." We must first choose whether to have a separate statement for each roundable parameter or whether to have a blanket statement at the start of each page saying which parameters may be rounded. I slightly favor a separate statement for each because we can explicitly state whether it should be rounded up or down more easily. If you agree with this, I also prefer the simpler statement used on page 8-34 except that we should add up or down after the word "round" as appropriate. What do you think? page 8-36, last paragraph - The sectors per track description is ambiguous. It isn't clear whether spare sectors on the track should be included or not (are spare sectors really "used" by the target?). Change the wording to ".. 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, this number is the average number of sectors per track for MODE SENSE and must be zero for MODE SELECT." page 8-37, paragraph 1, last sentence - change 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-37, paragraph 3 - skewing a constant number of "physical" sectors between the "last logical block" of one track and the "first logical block" of the next track may be difficult when using a spare sector per track scheme. Some spares will be assigned as logical blocks but most spares are not. The skew can always be constant between physical sectors, however. Change to the following wording: "The Track Skew Factor specifies the number of physical sectors between the last physical sector of one track and the first physical sector on the next sequential track of the same cylinder." page 8-37,paragraph 4 - same general comment as above. Change to the following wording: "The Cylinder Skew Factor specifies the number of physical sectors between the last physical sector of one cylinder and the first physical sector on the next sequential cylinder." page 8-40, paragraph 1 - Wording should be clarified to describe the way most vendors define this parameter. Instead of ".. used for data storage.", the words ".. included in the user addressable address space." are more clear. For example, spare cylinders are used only for data storage but are not included in the user address space and most vendors don't count them in this parameter either. If we aren't completely clear on this, different interpretations will exist and the parameter will become unpredictable and useless, like a vendor unique. page 8-40, paragraph 2 - First sentence should be modified the same as suggested for paragraph 1, above. In addition, the second sentence should have the word "only" added between the words "used for". This way people won't wonder if a head that reads both data and servo information should be counted or not.