RESERVE(6)/RELEASE(6) again, or the serial interpretations of SCSI-3.

dallas at zk3.dec.com dallas at zk3.dec.com
Fri Jun 21 08:30:48 PDT 1996


* From the SCSI Reflector, posted by:
* dallas at zk3.dec.com
*

John Scheible wrote.....


>    To avoid transport layer specific items in the device drivers, I
> assume that FCP would like to use PERSISTENT RESERVE/RELEASE.  However,
> I assume this is a big change for SCAM.  Also, since SSA is a "slight"
> modification over parallel SCSI, this is more code for SSA.  I cannot
> judge the impact to SBP.
> 
>    I see that we need to change the mandates of SCSI-3 that do not
> work for soft addressing schemes (FCP, SCAM), nor for large address
> schemes (wide parallel SCSI, FCP, SBP. S3P).  It is an impact to use
> RESERVE(6)/RELEASE(6) for narrow/wide SCSI, PERSISTENT RESERVE/RELEASE
> for soft addressing (SCAM, FCP), transport layer functions for SBP
> (although they could be hidden), and RESERVE(10)/RELEASE(10) for S3P
> and makes the device driver people roll over in their graves (after it
> kills them).
> 
>    Maybe this is a topic for the Serial Concerns meeting next month
> during the X3T10 plenary week?
> 
 
John, 

The impact to the peripheral drivers (PDs) is largely due to the
unresolved differences that each of the channels/buses presents.  The
SCSI command behaviors are just a part of the impact for the different
channels.  Error detection/behavior/recovery and addressing methods are
other factors that will require the PDs to have knowledge about the
channels it supports.

If we examine a typical SCSI-2 disk driver, around 90 percent of the
code deals with error cases.  The open, close, read and write routines
are a very small portion of the driver.  Most of the code within a
driver deals with errors, whether synchronous or asynchronous events
(e.g. resets, unit attentions, bad block replacement (if you don't
allow the disk to do bbr)).

The different channels have different methods for dealing with
channel/link type errors and data re-transmission.  Some channels deal
with the errors and data re-transmission in the SCSI protocol and/or
the link has recovery mechanisms (at a level below the PDs).  These
types of errors are typically handled in the SIM/channel code or the
adapter itself.  The recovery policies for these types of events are
channel type protocol specific and are best handled at that level.  If
the channel driver encounters an event that the recovery policies fail
to recover from then a generic error class (not channel specific) is
flagged back to the PD for the task that failed.  At that time the PD
would handle the error based on the device model recovery policies, not
channel model recovery policies.

The architecture of some of channels and/or the SCSI protocol are
lacking in functionality and will be presenting these types of errors
to the PDs.  This will require the PDs and the developers to have
knowledge of the channel behavior and to increase the error conditions
that each driver handles. 

Each of the SCSI PDs (disk, tape, scanner, etc.) now will have to have
code to deal with the different channel behaviors for each channel type
they support (FCP, SSA, SPI, etc.). If we look at how most SCSI I/O
subsystems are implemented/architected today and how development groups
are structured a common thread appears. Most SCSI I/O subsystems are
structured in a port class type arrangement where the PDs (class
drivers) know about the device model (disk, tape, scanner, etc.) and the
SIM/channel driver (port) knows about the hardware adapter and channel
characteristics.  The structure of the development groups is also
modeled along those same lines. A portion of the developers deal only
with class driver specifics and a portion of the developers deal
only with channel specifics with a manager or two thrown in to create
confusion.

I am a class driver developer, while I have done SIM/channel work I
prefer not to have detailed channel specific knowledge.  This will not
be the case if channel specific knowledge needs to be contained within
the class drivers.   I will take a stab at what I foresee the future
will be for SCSI class driver developement if channel specific
knowledge is bubbled up into the class drivers.  First I see that all
PD vendors will support SPI (since they already support SPI).  Second
the PD vendors will pick a serial channel that suits their market
needs.  The support for the other serial channels for a particular PD
will come later (if ever) for that PD and platform.  This is not the
future I had hoped for, what I had envisioned was that a PD that could
support any SCSI channel type without modification.

In my opinion each of the channels will be used in a number of system
ranges.  There are 3 main ranges of systems, which are Low, Medium and
High end systems.  Each of those ranges can be further in divided into
3 ranges within a range.  I have listed what channels I feel will be
used on the classified range of the systems.  The suitable use of a
channel for a system range is based upon performance, connectivity, and price.
Software development costs were not used as factor in the suitability
of use for channel. 

Low-low end systems: 
___________________
	SPI and SBP
Low-medium and low-high end systems: 
-----------------------------------
	SPI, SBP and SSA

Medium-low and medium-medium end systems: 
----------------------------------------
	SPI, SBP, and SSA

Medium-high end systems: 
-----------------------
	SSA and FCP

High-low end systems: 
--------------------
	FCP and SSA

High-medium and high-high end systems: 
-------------------------------------
	FCP

Note:  
The reason that I did not include SSA at the very high end is
the current bandwidth.

Note:	
The reason FCP is not listed on medium-medium end systems is cost.

You will notice that I do not consider a specific channel type suitable
enough to span all the system ranges.  The current different behavior
models that the channels present will present some hard choices to
software vendors on what channels to support.

Addressing for SCSI-2 devices was a small portion of the drivers code
space.  The new soft addressing mechanisms that came about in SCSI-3
presents a whole different model for the PDs and the SIMs (channel
drivers).  With the new addressing model the drivers can no longer rely
on the physical topology being constant across boots and during
runtime. Channel events for some channels can cause the address of a
device to change. The I/O subsystem must now change how the device 
topology is mapped and recognized.  From a single systems view there
can be many paths to a single device (e.g., a PD can send a command
to a device through multiple SCSI host adapters and still reach the 
device). 

SCSI-3 requires the PD developers to architect new mechanisms to map
the device topology.  The new software architectures will need to
uniquely identify a SCSI-3 device no matter where the device is in the
topology and the paths to the device. The topology mapping
architectures will need a consistent and mandatory mechanism to map the
devices at boot and to remap a device if its address changes (SBP, SCAM
FCP, etc.). As you point out, the PD's will need a consistent command
model to get rid of the per-channel command choices.  Currently SCSI-3
does not provide the mechanisms needed for device topology mapping and
each channel deals with it separately.



On a closing note, from what I have read SSA, is actively addressing
these and other issues for SCSI-3 to make SSA transparent to the PDs.
Thanks for making my job simpler.


Regards,
Bill Dallas





------- Replied-To Message

Date: Mon, 17 Jun 96 14:25:33 PDT
From: <scheible at VNET.IBM.COM>
  To: serial_concerns at zk3.dec.com, x3t10-ssa at symbios.com, scsi at symbios.com,
      dallas at zk3.dec.com
Subj: RESERVE(6)/RELEASE(6) again, or the serial interpretations of SCSI-3.


*
* From the serial_concerns Reflector, posted by:
* <scheible at VNET.IBM.COM>
*
* To post to this Reflector, send email addressed to serial_concerns at zk3.dec.co
  m
* Note: The "Reply-To:" address has been modified to point to the reflector
*

In response to my RESERVE(6)/RELEASE(6) note, Bill Dallas wrote...

> A solution would be to obsolete RESERVE and
> RELEASE (6) for SCSI-3 and mandate the 10 byte
> versions for SCSI-3 devices.  This solution is
> only a part solution since it does not address
> those devices that have soft addressing
> (FCP, SCAM, etc).
>
> Persistent Reserve could be a solution for SCSI-3
> devices where the RESERVE and RELEASE commands are
> obsoleted for SCSI-3 and Persistent Reserve mandated.
>
> From my view point any solution that does not require
> the peripheral drivers to have specific knowledge
> of an inter-connect is good.

   To avoid transport layer specific items in the device drivers, I
assume that FCP would like to use PERSISTENT RESERVE/RELEASE.  However,
I assume this is a big change for SCAM.  Also, since SSA is a "slight"
modification over parallel SCSI, this is more code for SSA.  I cannot
judge the impact to SBP.

   I see that we need to change the mandates of SCSI-3 that do not
work for soft addressing schemes (FCP, SCAM), nor for large address
schemes (wide parallel SCSI, FCP, SBP. S3P).  It is an impact to use
RESERVE(6)/RELEASE(6) for narrow/wide SCSI, PERSISTENT RESERVE/RELEASE
for soft addressing (SCAM, FCP), transport layer functions for SBP
(although they could be hidden), and RESERVE(10)/RELEASE(10) for S3P
and makes the device driver people roll over in their graves (after it
kills them).

   Maybe this is a topic for the Serial Concerns meeting next month
during the X3T10 plenary week?

Any thoughts?

Thanks,
John Scheible
scheible at vnet.ibm.com

*********************************************************************
To unsubscribe from this list, send mail to majordomo at zk3.dec.com or
ALPHA::MAJORDOMO (from VMS) with the following text:
unsubscribe serial_concerns

For help with the majordomo commands, the text should be:
help
*********************************************************************

------- End of Replied-To Message




More information about the T10 mailing list