Set Capacity Proposal, rev. 3

Hallam, Ken MV KHallam at
Tue Jan 2 13:58:00 PST 1996

* From the SCSI Reflector, posted by:
* <"Hallam, Ken                 MV" <KHallam at>>


Regarding your newly revised Set Capacity Proposal, I'm sorry to say I don't 
think it's a good idea. To have 2 different block descriptors, one for disk 
and one for tape is really UGLY.

We've only just started to get our vendors to use the Density Codes in the 
block descriptors in a consistant manner and now you propose to change the 
rules. I realize the reason for moving the Density Code field is that you 
wanted to keep the LSB for the Number of Blocks field in the same place. 
However, moving the Density Code field screws up our system code 
considerably. We prefer to deal with all block descriptors in the same way 
and to keep the fields in the same relative locations wherever possible. I 
think its also a goal of the SCSI-3 draft efforts to keep things consistent 
and coherent.

Leaving the Density Code where it is and using RESERVED byte 4 to expand the 
Number of Blocks field leaves us with the problem of a new location for the 
LSB and potential misinterpretation by older software drivers. (Just as bad 
as relocating the Density Code field and having it misinterpreted.) It seems 
unfair to ask those of us who support streaming devices, (and many of those 
who support block devices with no interest in changing the native capacity 
of a device) to assume a burden in software compatibility to satisfy one 
particular application. Especially when a more reasonable alternative 

What was wrong with the suggested method in revision 2? An expansion to the 
READ CAPACITY comand seems logical and reasonable, while manipulation of the 
Block Descriptor is awkward and fraught with potential compatibility 
problems. I don't recall the discussions of the November 7, 1995 working 
group that led to the abandonment of the READ CAPACITY modifications but it 
seems we have traded one fairly straightforward implementation for a much 
more indirect method of achieving your goals that will in all probability, 
require a READ CAPACITY to be issued simply to see what effect the block 
descriptor change had, if any. I realize the WG indicated it wanted to do 
things this way at the last meeting, but it won't be the first time the WG 
has set the wrong course. Jjust because someone was planning, (or has 
implemented) the block descriptor method of changing capacity does not make 
it Holy Writ.

I suggest we look at the expansion of the READ CAPACITY command again.

Does anyone else out there have an issue with the way this propsal has 

Ken Hallam
ken.hallam at
From: scsi-owner
To: scsi
Subject: Set Capacity Proposal, rev. 3
Date: Thursday, December 28, 1995 10:42AM

* From the SCSI Reflector, posted by:
* <Gerry Houlder  <Gerry_Houlder at>>
Date:  Dec. 28, 1995
To: X3T10 Committee
From: Gerry Houlder, Seagate Technology
Subj: Set Capacity Proposal

This proposal came about because some customers want to define the capacity
reported by a disk drive as something less than its full capacity. The main
reason for this is customers wanting drives from different vendors to have
exactly the same number of logical blocks. This is desired for ease of
replacement, especially in disk array applications.

Another reason is that drives are getting too large for some operating 
to handle. For example, many operating systems will only handle 8 GB of 
on a single device and several vendors are making drives with a larger
capacity than this.

Rev. 0: Initial proposal to modify the Block Descriptor in MODE SELECT so 
the Number of Blocks Field is expanded to 4 bytes.

Rev. 1: In discussions at the July 11 working group meeting, about 60% of 
group felt that the backwards compatibility issues caused by extending the 
SELECT Block Descriptor to 4 bytes made this option unacceptable. The group 
favor adding a set capacity capability to the READ CAPACITY command. Rev. 1
related the changes needed to do this.

Rev. 2: In discussions at Sept. 12 working group meeting, the group 
that any reference to using the set capacity feature to split drive capacity 

across multiple LUNs be deleted. There were too many unresolved issues (such 
how FORMAT command operated on the multiple LUNs) for the group to accept 
feature. Also some wording changes were made in the paragraph describing
reservation conflict cases.

Rev. 3: In discussions at Nov. 7 working group meeting, it was pointed out 
several companies in the industry will use the technique described in Rev. 0 
this proposal. The group decided it was better to document that technique
rather than create a new one that is radically different.

I propose using a new block descriptor format (with a 4 byte number of 
field) for direct access, write-once, CD-ROM, optical, and array peripheral
device types (codes 00h, 04h, 05h, 07h, and 0Ch respectively). These are the 

types that refer to the SBC document for at least some of their commands. 
other types will use the existing block descriptor format. Some types (e.g., 

streaming devices) need the density code field to stay where it is.

This is better than using a block descriptor type field in the header 
only the 10 byte MODE SELECT version of the header has room to add such a
field. This would require the 6 byte version to stay with the existing 
which has a 3 byte number of blocks field.

The SPC must add a new mode parameter block descriptor section. It should 
as described on the next page. If this proposal is accepted, the existing 
descriptor wording can be changed to delete wording specific to SBC type
devices since those devices will be covered by this new block descriptor. 
document editor shall be empowered to make such related changes to the 
block descriptor wording that he deems appropriate.

[New section to be added to SPC document]

 Table xx - Mode parameter block descriptor for block devices

0  |  (MSB)                                       |
 ---|--                                          --|
1  |           Number of blocks                   |
 ---|--                                          --|
2  |                                              |
 ---|--                                          --|
3  |                                       (LSB)  |
4  |           Density code                       |
5  |  (MSB)                                       |
 ---|--                                          --|
6  |           Block length                       |
 ---|--                                          --|
7  |                                       (LSB)  |

This block descriptor format applies only to direct-access, write-once, 
memory,  and array controller devices. All other device types use another 
descriptor format. Block descriptors specify some of the medium 
for a logical unit. Support for block descriptors is optional. Each block
descriptor contains a density code field, a number of blocks field, and a 
length field. A unit attention condition as described in clause 7.8 shall be 

generated when any block descriptor values are changed.

The number of blocks field specifies the number of logical blocks on the 
to which the density code and block length fields apply. A value of zero
indicates that all of the remaining logical blocks of the logical unit shall 

have the medium characteristics specified. If the number of blocks field
contains 00FFFFFFh, it shall be interpreted to mean that the number of 
is greater than 00FFFFFEh. In this case the READ CAPACITY command may be 
to determine the actual number of blocks for the device. (See SBC standard 

If the SCSI device doesn't support changing its capacity by changing the 
of blocks field (via a MODE SELECT command), the value in the number of 
field is ignored. If the device supports changing its capacity by changing 
number of blocks field, then the number of blocks field is interpreted as 

a) If the number of blocks is set to zero, the device shall be set to its
maximum capacity. If the block size has not changed, the device shall not
become format corrupted. This capacity setting shall be retained through 
events or power cycles.
b) If the number of blocks is greater than zero and less than or equal to 
maximum capacity, the device shall be set to that number of blocks. If the
block size has not changed, the device shall not become format corrupted. 
capacity setting shall be retained through reset events or power cycles.
c) If the number of blocks field is set to a value greater than the maximum
capacity of the device then the command is terminated with a CHECK CONDITION 

status, the sense key is set to ILLEGAL REQUEST, and the additional sense 
is set to LOGICAL BLOCK ADDRESS OUT OF RANGE. The device retains its 
block descriptor settings.

52  There may be implicit association between parameters defined in the 
and block descriptor. For direct-access devices, the block length affects 
optimum values (the value that achieves the best performance) for the 
per track, bytes per physical sector, track skew factor, and cylinder skew
factor fields in the format parameters page. In this case, the target may
change parameters not explicitly sent with the MODE SELECT command. A
subsequent MODE SENSE command would reflect these changes.

The density code field is unique for each device type. Refer to the mode
parameters clause of the specific device type command standard (e.g., SBC) 
the definition of this field. Some device types reserve all or part of this

The block length specifies the length in bytes of each logical block 
by the block descriptor. If the block length is changed, the new value is 
saved until a FORMAT command is received. When the block length is changed, 
device shall indicate a format corrupted condition until a FORMAT command is 

received or the block length is restored to its previous value.

More information about the T10 mailing list