Inadequacy of Number of Blocks in Mode Select/Sense

Bob Snively Bob.Snively at Eng.Sun.COM
Tue May 30 10:23:00 PDT 1995

>From Gerry_Houlder at Fri May 26 21:24:11 1995
>Date: 26 May 95 17:04:04 EDT
>Subject: Inadequacy of Number of Blocks in Mode Select/Sense
>The Number of Blocks field in the MODE SELECT/SENSE block descriptor is defined 
>as only 3 bytes. This is inadequate for some current products and will become 
>more so in the future. The standard allows for setting 0xFFFFFF in this field 
>when the actual capacity is greater than this, but this isn't useful for some 
>current applications.

I am frankly a little unclear on what the block descriptors are useful for,
aside from setting the block length for a certain extent of logical blocks.
In most present disk devices, the block length is normally the same for the
entire disk, and almost always set to 512 bytes.  If in fact they are
useful for something and calling out multiple block descriptors (which
would suffice for capacities up to about 266 Gbytes) is unacceptable,
then we could expand the block descriptor value.  However, I do not favor adding
these other additonal functions to the block descriptor definition.

>Some customers use this field on MODE SELECT to set the capacity that the drive 
>will report. While this usage is not sanctioned by the SCSI-2 or -3 standards, 
>there is enough customer demand to force vendor unique methods of doing this if 
>the standard doesn't allow for it. I do not want to be forced into supporting 
>several different vendor unique ways to do this; it is better to extend the 
>standard to support it.

The only "sanctioned" method for modifying the reporting values is to
change the physical geometry values, cutting out cylinders, tracks, or
sectors of information.  Again, most drives and operating systems use
any old capacity that is provided to them, then the operating system places
any necessary restrictions on how much of that capacity is actually
exposed to the user and for what purposes.  If in fact someone really
needs to modify the READ CAPACITY returned value, then an appropriate
optional standard mode page should be created that does that, although
I would hope that it never happens.  It is another item that thickens
the spec and reduces code reliability.

>Another reason for a customer to want this is to split a drive into multiple 
>LUNs. When capacity on one drive is too large to be handled as one LUN, a 
>method is desired to split it into several LUNs. Using several block 
>descriptors (one for each LUN) in MODE SELECT is one possible method of doing 
>this. Does anyone have a better idea? 

I think that the SCC command set has established commands focused
on precisely this problem, and would commend their use.  The
block descriptor is basically an extent length for blocks of a certain
class and does not create a LUN boundary that separates
properties with respect to mode select functions, task management functions,
tagged queueing and other LUN boundary related things.  Remember that
block descriptor values "are always current (i.e. saving is not supported)."

>This could be fixed by defining a different block descriptor format for 10 byte 
>MODE SELECT/SENSE commands that allocates 4 bytes for the Number of Blocks 
>field. The block descriptor can remain 8 bytes long by defining it as follows:
>Bytes 0-3:   Number of Blocks Field
>Byte 4:         Density Code (same as byte 0 in present block descriptor)
>Bytes 5-7:   Block Length
>I know that defining a new block descriptor for use with 10 byte MODE 
>SELECT/SENSE commands has some backward compatibility problems, but few 
>customers are actually using these commands yet and the added functionality 
>will be worth the pain for the few that do. I am interested in knowing who has 
>opinions on this.

Yup,  that is why my first impression is that we should not do it.

More information about the T10 mailing list