ESI modifications proposed for revision 2.1
Bob Snively
Bob.Snively at Eng.Sun.COM
Fri Feb 9 22:46:51 PST 1996
* From the SCSI Reflector, posted by:
* Bob.Snively at Eng.Sun.COM (Bob Snively)
*
To: Distribution
From: Bob Snively
Date: February 7, 1996
Subject: Notes on ESI
The following issues were raised by a discussion of the
ESI document with Jim Coomes of Seagate. I believe that
these changes are mostly editorial clarifications and do not
change theintent of the text. I will either make these corrections
or include them in the questions and issues and
release a new modified version of this proposal before the
ESI meeting.
1) Section 8.1 description of parameter truncation, P 4
The definition describing the truncation of parameters during
the execution of SEND DIAGNOSTIC will not work properly with
devices that pass ESI information through without knowing the
structure of the parameter list. The valid approaches might be:
a) Require the page_length + 4 to be equal to the
allocation length or else post a check condition.
If they are equal, that is the length of transfer
that will be performed. If they are different,
the transfer length will be the allocation length
or the first 4 page bytes, whichever is shorter.
b) Allow the page_length + 4 to be any value and
the allocation length to be any value. Transmit
the lesser or the page_length + 4 or the allocation
length. If the ESI information is invalid, this
can be returned in a subsequent ESI status
page, probably as an informative condition.
I have modified the document to take the first approach.
Note that invalid pages can still be sent and valid short pages
can still be sent, unless we choose to explicitly prohibit them
and require the outbound pages to be precisely the length required
by the configuration page. At present, I have not modified the
document to prohibit the use of invalid or shortened valid pages.
2) Clarification of normal and short status pages
Table bb on page 9 defines the format of the normal (as opposed
to short) status page. As a result, it implies that bits
3-0 of byte 1 should always have the specified value. To correct
this mis-impression, the title is changed to:
Table bb - Normal enclosure services status page
In addition, the entry for bit 7 of byte 1 is modified to read:
Short (=0)
3) ESI operations for SFF-8045 drives always present short status
This is properly noted in most of the outbound pages. For section,
8.1.6, it has been inadvertently omitted and will be included as it
was for the other sections.
4) SCSI Bus described
The SCSI documents should not refer to the SCSI Bus, but rather to
a SCSI connection, since most SCSI devices will not be using a bus.
This must be corrected in section 11.1 and anywhere else it is found.
5) Clarify use of ESI commands by non-ESI devices
The text of 11.1 and 11.2 does not make it perfectly clear that
there are really two different ways to access enclosure services.
They may be accessed either through an enclosure services
device type logical unit (having a device type of 0Dh as shown
in the response to an INQUIRY command) or through an enclosure
services command set (SEND DIAGNOSTIC, RECEIVE DIAGNOSTIC RESULTS)
on any other type of logical unit. The text will be modified to
clarify this.
6) Clarify error presentation differences for ESI and non-ESI devices
Section 2.4 presently does not distinguish that there are basically
two classes of errors. One can be detected by ESI type devices and
involves lots of different abnormalities in the formation of the
ESI string. A second can be detected by normal devices that transport
ESI strings to an ESI processor. These have only to do with the
proper shape of the string, since the device does not parse the
string and verify its contents. Section 2.4 will be clarified accordingly.
7) Examine EFW requirements
It has been proposed that the EFW function be removed. The basic problem is
that the management of the -PARALLEL ESI signal must change according to
whether or not the enclosure is an 8045 or an 8067 enclosure. Once that
is done, it is then necessary to sample the EFW signal according to
complex rules.
It would be simpler to simply remove it and let the device take care
of itself, except for those disconnection management services that the
enclosure could legitimately provide.
8) Remove redundant EFW requirement
The last bullet of the final EFW mode is redundant and may be removed.
9) Is it possible to ignore directives to the ESI function.
An additional discussion item was identified by Rod Dekonin of
Symbios. He notes that some enclosure functions may nominally be
observable from device status and controlled by host actions
to individual enclosure services type devices. It is possible that
RAID controller management of the enclosure or self-protective
behavior of the enclosure may require that some other process over-ride the
enclosure services control page functions. It is also possible that
some functions are completely taken over by the RAID controller so that
control actions through the ESI command set are ignored. I believe that
his interpretation is correct and that almost all ESI control entries
are optional and may be ignored, overriden, or re-interpreted by
the ESI services device or by other controllers that share the
responsibility for managing the enclosure. Several sections need
minor modifications to make this very clear.
More information about the T10
mailing list