97-234r0 -- LUN_Z Capabilities Bit in SPC-2

dallas at zk3.dec.com dallas at zk3.dec.com
Fri Aug 29 13:29:07 PDT 1997


* From the T10 (formerly SCSI) Reflector (t10 at symbios.com), posted by:
* dallas at zk3.dec.com
*

Ralph,

I disagree with your comments and feel that the operating
systems are broken that do not handle this case.  Any OS that 
expects a limited set of devices (tape or disk type) at LUN 0 
is deficient.

The model for the SCC commnad set at LUN 0 is very clean and
distinct.  The addition of the bit adds complexity where
complexity is not needed.  

There are a number of issues with this proposed change.  The
most important of which is event reporting.  In a strict device
driver model you have separate drivers for each class of 
device.  One for SCC and one for disks.  For example, 
both are operating on that LUN 0 which is both (SCC/disk) and 
an event happens.  Which one gets the event (Check condition)
or does both? What happens to the task set? Which driver is 
the correct one to perform error recovery?  These types of
issues must be addressed.

The OSs that don't handle other device types at LUN 0 are going
to change either way.  They will have to either modify the 
drivers to handle a combined SCC/disk/etc. LUN 0 event model or
change to handle other device types at LUN 0.

Changes to a driver to handle a combined device type event/error 
model is much more extensive then changes to recognize that a
disk/tape can be at LUNs other then 0.


Thanks 
Bill

------- Replied-To Message

Date: Fri, 29 Aug 1997 11:15:33 -0400
From: ROWEBER%acm.org at us2rmc.enet.dec.com (MAIL-11 Daemon)
  To: T10 at symbios.com
Subj: 97-234r0 -- LUN_Z Capabilities Bit in SPC-2

* From the T10 (formerly SCSI) Reflector (t10 at symbios.com), posted by:
* ROWEBER at acm.org
*
                                                              T10/97-234r0
 
    Date:	21 August, 1997
    To:		T10 Membership
    From:	Ralph Weber, X3T10 Alternate member from Symbios Logic
    Subject:	LUN_Z Capabilities Bit in SPC-2


Problem Statement

SCC and SCC-2 require the logical unit at LUN=0 to have a device type of
'storage Array controller device' (0Ch). However, many operating systems
require the LUN=0 unit to have a device type of 'direct access' (00h) or
'sequent- ial access' (01h) for the purposes of their configuration
scanning code.  Also, there is no reason why a RAID device cannot have a
virtual unit at LUN=0.

I have submitted a letter ballot comment, which if accepted will change
this.  Yet, additional changes are needed in SPC-2 to support the proposed
letter ballot change in SCC-2.

Proposed Changes

A bit must be defined in the Standard Inquiry Data that, when set,
indicates that the logical unit supports the SCC command set in addition to
the command set identified by the device type.  It is recommended that this
bit be called LUN_Z and that it be bit 0 in byte 5.

In Table B.2 (the operation code numerical list), O (for optional) must be
added in the D (disk), T (tape), W (write-once), O (optical), M (medium
changer), and E (enclosure) columns for the following commands:

	A3h	MAINTENANCE (IN)
	A4h	MAINTENANCE (OUT)
	BAh	REDUNDANCY GROUP (IN)
	BBh	REDUNDANCY GROUP (OUT)
	BCh	SPARE (IN)
	BDh	SPARE (OUT)
	BEh	VOLUME SET (IN)
	BFh	VOLUME SET (OUT)

Note: It would be nice to be able to include the R (CD-ROM) column in the
list above.  But, this is not possible because CD-ROM defines several of
these operation codes for other uses.  Perhaps this can be resolved as part
of the DVD work.  Otherwise, it will not be possible to have LUN=0 be both
a CD-ROM device and a RAID controller device.  If no resolution can be
reached, perhaps giving software developers sufficient notice of this
restriction will allow them to design system configuration scanning code
that deals with it.
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at symbios.com

% ====== Internet headers and postmarks ======
% Received: from mail13.digital.com by us2rmc.zko.dec.com (5.65/rmc-22feb94) id
   AA22009; Fri, 29 Aug 97 10:54:34 -0400
% Received: from mpdgw2.symbios.com (mpdgw2.symbios.com [204.131.200.2]) by mai
  l13.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id KAA25378 for <Dallas at wast
  ed.enet.dec.com>; Fri, 29 Aug 1997 10:46:42 -0400 (EDT)
% Received: (from root at localhost) by mpdgw2.symbios.com (8.6.8.1/8.6.6) id IAA0
  5026; Fri, 29 Aug 1997 08:43:02 -0600
% Received: from aztec.co.symbios.com(153.72.199.214) by mpdgw2.symbios.com via
   smap (V1.3) id sma004750; Fri Aug 29 08:42:25 1997
% Received: (from majordom at localhost) by Symbios.COM (8.6.8.1/8.6.6) id IAA2119
  7 for t10-outgoing; Fri, 29 Aug 1997 08:40:59 -0600
% Received: from mpdgw2.symbios.com (bastion.symbios.com [204.131.201.2]) by Sy
  mbios.COM (8.6.8.1/8.6.6) with ESMTP id IAA21190 for <T10 at symbios.com>; Fri, 
  29 Aug 1997 08:40:57 -0600
% Received: (from root at localhost) by mpdgw2.symbios.com (8.6.8.1/8.6.6) id IAA0
  4335 for <T10 at symbios.com>; Fri, 29 Aug 1997 08:40:58 -0600
% Received: from pascal.acm.org(192.135.174.1) by mpdgw2.symbios.com via smap (
  V1.3) id smaa04266; Fri Aug 29 08:40:50 1997
% Received: from PASCAL.ACM.ORG by PASCAL.ACM.ORG (PMDF V5.1-5 #22743) id <01IN
  0A0S7VNK00P15Q at PASCAL.ACM.ORG> for T10 at symbios.com; Fri, 29 Aug 1997 09:40:45
   -0500 (CDT)
% Date: Fri, 29 Aug 1997 09:40:45 -0500 (CDT)
% From: ROWEBER at acm.org
% Subject: 97-234r0 -- LUN_Z Capabilities Bit in SPC-2
% To: T10 at Symbios.COM
% Message-Id: <01IN0A0S99KY00P15Q at PASCAL.ACM.ORG>
% X-Vms-To: @s__:auto$mail$2
% Mime-Version: 1.0
% Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
% Sender: owner-t10 at Symbios.COM
% Precedence: bulk

------- End of Replied-To Message
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at symbios.com




More information about the T10 mailing list