Your SBC Comments
Gene Milligan
Gene_Milligan at notes.seagate.com
Mon Oct 14 16:10:44 PDT 1996
* 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
More information about the T10
mailing list