Set Capacity Proposal, rev. 3
Hallam, Ken MV
KHallam at po2.mv.unisys.com
Tue Jan 2 13:58:00 PST 1996
* From the SCSI Reflector, posted by:
* <"Hallam, Ken MV" <KHallam at po2.mv.unisys.com>>
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
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 at mv.unisys.com
Subject: Set Capacity Proposal, rev. 3
Date: Thursday, December 28, 1995 10:42AM
* From the SCSI Reflector, posted by:
* <Gerry Houlder <Gerry_Houlder at notes.seagate.com>>
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
READ CAPACITY command.)
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