Inadequacy of Number of Blocks in Mode Select/Sense

Stephen Holmstead stephen at
Tue May 30 16:59:10 PDT 1995

Gerry Houlder wrote:
>The Number of Blocks field in the MODE SELECT/SENSE block descriptor is
>defined as only 3 bytes. This is inadequate . . . [stuff deleted]

I agree.  We have also been trying to figure out a way to overcome this

Bob Snively replied:
|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.

Despite the fact that allowing the Number Of Blocks field in the Block
Descriptor is not "sanctioned", it has become a "defacto" industry standard.
I also understand that this can accomplished in a number of different ways.
However, modifying the Physical Geometry mode page is NOT one of them, since
this mode page rarely has any meaningful information on it due to the
zoning that exists on almost all drives today and the inadequacy of that
mode page to be able to represent that information.

I also understand that the operating system can restrict addressing to
those extra blocks.  But, I am NOT the customer; the customer pays the money,
so what the customer wants, the customer gets.

The entire need for this feature was created because of the need for multi-
sourcing of disks.  So we MUST decide on a standard method of solving

Gerry Houlder 's comments:
>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.

For disks, this provides NO backwards compatibility issues since the
Density Code is always 0 for disks.  The only folks who use the Density Code
are the tape folks, and they are currently working on a new method of
providing this information.  In fact, at the last X3T10 meeting, a decision
was made to put off assigning new Density Codes to the QIC folks because
of a proposal in progress.

I agree with Gerry's proposal and I would HATE to see a new mode page just
for this purpose.

 ____       ____
|   / /_  __\   | Disk       Stephen Holmstead            All comments (c)1995
|  | / / /_/ |  | Memory     stephen at      My opinions should
|___\   /   /___| Division   Fax: 208/396-6858            be held by everyone

More information about the T10 mailing list