Inadequacy of Number of Blocks in Mode Select/Sense

Gerry Houlder Gerry_Houlder at
Fri May 26 14:04:04 PDT 1995

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.

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.

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? 

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.

More information about the T10 mailing list