Your SBC Comments

[Gene Milligan]

* From the SCSI Reflector (scsi at symbios.com), posted by:
* Gene Milligan <Gene_Milligan at notes.seagate.com>
*
To: LJLamers @ aol.com @ INTERNET
cc: GOP @ RCHVMP3.VNET.IBM.COM @ INTERNET 
From: Gene Milligan
Date: 10/14/96 04:10:08 PM
Subject: Your SBC Comments

Thank you again for the marked up document. I have made the changes you 
suggested except for a few cases. I have a few problems with a few of the 
comments as noted below. I am copying the SCSI reflector in case someone out 
there may wish to comment on any of these items.

1) You commented on the definition "check data: Information contained within a 
redundancy group that allows lost or destroyed user data to be recreated." Your 
comment was that it did not have to be lost or destroyed. My response is:

 a) I agree it does not have to be. But the definition is "allows".

 b) The definition is verbatim from SCC and I do not want to change it unless 
we plan to make the same change in a future version of SCC.

2) You questioned the definition "extent: An extent is a specified number of 
logical blocks and are all or part of a block device." Can it span devices? The 
answer is no. If the extent reservation were sent to a SCC device the result 
might span beyond one SBC device. But reservations sent to a SBC device can not 
in themselves span beyond the block device.

3) For 5.1.2 Logical Blocks you asked if the READ CAPACITY commands determines 
the values of n rather than [n-1]. I think you could look at it either way. But 
the READ CAPACITY command returns the logical block address of the last logical 
block such that it literally corresponds to [n-1] rather than n. I did change 
it to italics.

4) I think you suggested a global change to Sense key : Sense code which I 
guess would be, for example, changing "a sense key of ILLEGAL REQUEST and the 
additional sense code shall be set to LOW POWER CONDITION ACTIVE." to "a sense 
key  : sense code of ILLEGAL REQUEST : LOW POWER CONDITION ACTIVE." But the 
style you commented on is the same as used in SPC so I have not made a change.

5) In "The command sequences use the device server to perform the xor functions 
needed for the major operations." you questioned the word "major". I think the 
point being referred to here is that the "major operation" REGENERATE will 
result in the device server generating "minor operations" such as READ. 
Consequently I left the wording.

6) Regarding the Regenerate operation you questioned the use of "old data" in 
places like "1) This transfers the old data from the device to the array 
controller." I agree that "old data" may not be the best terminology.  You 
either did not object to "new data" used in the Update WRITE  operation or of 
course could have passed over it without the phrase registering. But I presume 
"old data" is as valid as "new data". However "old data" permeates the 
description and is even shown in the XOR Annex A. Consequently I do not want to 
change the term "old data" without committee consensus.

7) Regarding "1) A WRITE command is sent to the replacement device. This 
transfers the final xor result data from step 4 to the replacement device. The 
device writes this data to the medium." you suggested deleting "The device 
writes this data to the medium."  I think this is an essential step not 
described if the sentence is deleted. Instead I changed it to "1) A WRITE 
command is sent to the replacement device. This transfers the final xor result 
data from step 4 to the replacement device. The replacement device writes this 
data to the medium."

8) In the secondary errors clause you marked a couple paragraphs with double 
bars which I presume is standard editing terminology. However I don't know 
standard editing terminology.

9) You questioned the use of "return" rather than "sent" in "the device server 
shall return CHECK CONDITION status ". I understand that there has been debate, 
and perhaps resolution, as to what words like "return" mean in terms of various 
serial architectures and for that matter perhaps in various host architectures. 
I do not think it has been productive to tinker with the long standing 
descriptions in the command sets to neuter there description except where there 
is a clear conflict that must be resolved in the command set rather than in the 
transport protocol. At any rate this is the same terminology used by SPC. I d
efer any change in this area unless agreed to globally by the committee.

10) Relative to "The READ(10) command (see Table 15) requests that the device 
server transfer data to the application client.  The most recent data value 
written in the addressed logical block shall be returned.  " you asked about 
the affect of write-back caching. The literal answer to your question is "The 
algorithm used to manage the cache memory is not part of this standard. "  
While it is not part of the standard it is certainly assumed that the algorithm 
causes the apparently written data to be read when a subsequent READ command 
occurs. Although the algorithm is not specified, there are some related 
specifications in the standard:

"A force unit access (FUA) bit of one indicates that the device server shall 
access the media in performing the command prior to returning GOOD status.   
Read commands shall access the specified logical blocks from the media (i.e.,  
the data is not directly retrieved from the cache). If the cache contains a 
more recent version of a logical block than the media, the logical block shall 
first be written to the media. "

"An FUA bit of zero indicates that the device server may satisfy the command by 
accessing the cache memory.  For read operations, any logical blocks that are 
contained in the cache memory may be transferred to the application client 
directly from the cache memory. " In this case I would interpret this to mean 
the write-back cached blocks.

11) In "If the REASSIGN BLOCKS command failed due to an unexpected 
unrecoverable read error that would cause the loss of data in a block not 
specified in the defect list, the logical block address of the unrecoverable 
block shall be returned in the information field of the sense data and the 
valid bit shall be set to one. " you suggested that "would" be changed to 
"may". I do not agree, "would" is not permissive, it is definite. It does not 
match the key word may.

12) You suggested changing, in REZERO UNIT command, " If the device server 
would set the block device to a vendor-specific state that may affect the 
manner that any other initiator uses to accesses any extent, an extent 
reservation conflict shall be detected. REZERO UNIT commands with a reservation 
conflict shall be terminated with CHECK CONDITION status and the sense key 
shall be set to DATA PROTECT if any part of the REZERO UNIT operation is 
prohibited by an extent reservation." to " If the device server sets the block 
device to a vendor-specific state that may affect  initiator accesses to any 
extent, an extent reservation conflict shall be detected. REZERO UNIT commands 
with a reservation conflict shall be terminated with CHECK CONDITION status and 
the sense key shall be set to DATA PROTECT if any part of the REZERO UNIT 
operation is prohibited by an extent reservation." I don't agree with the 
suggestion on two points. The device server does not actually set the block 
device to the state, it detects the requested problem and instead reports the 
reservation conflict. The other point is that if the offending initiator is 
causing the  vendor-specific state and this  is already the state the device 
server is in for the other initiators the state can be reentered without error 
and a reservation conflict does not exist.

13) Several places you suggested deleting the phrase "fourteen-byte " in 
statements such as "The SEARCH DATA parameter list (see Table 30) contains a 
fourteen-byte header, followed by one or more search argument descriptors." I 
do not understand the reason for these suggestions. So for now, I skipped them.

14) I don't know if it is related to this, but on the cover you have the global 
statement "Header format". I need more information concerning this comment.

15) Another global comment I need more information on is "is/set/clear".

16) In SEARCH DATA HIGH and SEARCH DATA LOW you suggested deleting the 
operation codes. I did not since these clauses specify which of the three 
operation codes in the Table parse to which command. Including the operation 
code is much more direct than instead putting in a reference back to the table 
that lists all commands.

17) Regarding "There shall be no indication from the block device that it has 
entered the requested power condition. An application client may determine if a 
power condition is active by issuing a request sense command to the logical 
unit (see 5.1.4)." You asked How? SPC states:

"If the device server is in the Standby power condition or Idle power condition 
when a REQUEST SENSE command is received and there is no ACA condition, the 
device server shall return a sense key of NO SENSE and an additional sense code 
of LOW POWER CONDITION ON. On completion of the command the logical unit shall 
return to same power condition that was active before the REQUEST SENSE command 
was received. A REQUEST SENSE command shall not reset any active power 
condition timers."

Part of your concern was whether or not SBC devices support polled sense. SPC 
makes the support mandatory for devices implementing Standby or Idle power 
conditions.

18) You pointed out that requirement (c) of the START STOP UNIT command is 
redundant to the requirement in the power condition model. I agree and will 
delete the requirement in the model if the committee agrees. However I did not 
make the change in Rev 6.

19) Also you noted that the Power condition values in the text needed the hex 
designator which I added. You also called for labels which I presume are the 
descriptions. They seem to long to add to the text and I did not make this 
change.

20) You asked if a SYNCHRONIZE CACHE is performed prior to entering sleep? Good 
design practice would do so. However the standard is silent on this. In 
addition the wording right now is only when executing a STOP command. We do not 
have a STOP command. Consequently it might be possible to construe that a START 
STOP UNIT command was being referred to which might drag in the Sleep 
condition. Before changing STOP command to START STOP UNIT command with the 
Start be cleared to zero, I think the technical committee should agree to an 
obvious technical change of requiring SYNCHRONIZE CACHE prior to entering Sleep.

21) You noted that the SET LIMITS(12) and WRITE(12) commands should be made 
optional for all block devices. I agree with this but since it would be a 
technical change we need to get technical committee concurrence. I suggest we 
look at all the commands in the subsets to see if they should be general.

22) You questioned the last   phrase in "Each notch shall span a set of 
consecutive logical blocks on the block device, the notches shall not overlap, 
and no logical block shall be excluded from a notch." This is exactly the 
SCSI-2 wording. I think the requirement is that if you walk through all the 
notches and add up the logical blocks described, the total number of blocks is 
required to be the same result that you would get if you did a READ CAPACITY 
command. 

23) You suggested deleting the page code in "The power condition page (see 
Table 91) is an optional alternative to the power condition page code 1Ah 
defined in SPC that provides the application client the means to control the 
length of time a block device delays before changing its power requirements." 
and the following discussion. But SPC does mention both page codes. I think it 
is important to be clear to the point perhaps of some small redundancy since 
some people are confused by this page having two page codes.

24) Your comment (23) put me in the vicinity of the statement "There is no 
notification to the application client that a block device has entered into one 
of the power conditions." This statement is not the whole truth. There is a 
notification when the device enters some of the power conditions when it enters 
them from sleep. I think we need to adjust this statement.

25) You marked "committee reference" next to the Optical memory density codes 
table. I do not know what you had in mind by this comment.


Gene
 

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