Programmable capacity revisited
Gerry_Houlder at notes.seagate.com
Fri Apr 19 06:30:07 PDT 1996
* From the SCSI Reflector, posted by:
* Gerry Houlder <Gerry_Houlder at notes.seagate.com>
Someone has pointed out that the current programmable capacity algorithm causes
big problems for devices that always return zeros in the Number of Blocks
field. The problem goes like this:
1) The drive is set to a capacity lower than the maximum possible because the
customer desires that capacity.
2) The initiator does MODE SENSE to get current settings for a mode page. The
returned data includes the block descriptor (with zeros in the Number of Blocks
3) The initiator clears the reserved bits in bytes 0, 1, 2 of the header and
the PS bit in the page code byte. It also changes the desired parameter in the
4) The initiator sends MODE SELECT with the new mode page data. This results in
the new mode data being set, but it also results in the capacity changing to
its maximum. This change is not desired by the customer.
If the drive returns zeros in the Number of Blocks field regardless of its
actual capacity, it is troublesome to do any MODE SELECT commands that don't
alter the capacity. One method is to use the DBD bit in MODE SENSE so the block
descriptor isn't returned. The other method is to do a READ CAPACITY command
and use the returned Last LBA information to fill in the Number of Blocks
field of the MODE SELECT data (I don't recommend this, but it does work).
I will submit a new proposal that allows a value of zero in the Number of
Blocks field to allow the drive to retain its existing capacity. The only
consequence of this is that all Fs must be used to force the drive to its
maximum capacity instead of zeros. This will result in new/changed wording
that is marked with > in column 1:
If the device supports changing its capacity by changing the number of blocks
the number of blocks field is interpreted as follows:
> a) If the number of blocks is set to zero, the device shall retain its
current capacity if the
> block size has not changed. If the block size has changed, then the device
> vendor specific.
b) If the number of blocks is greater than zero and less than or equal to its
the device shall be set to that number of blocks. If the block size has not
changed, the device
shall not become format corrupted. This capacity setting shall be retained
events or power cycles.
c) If the number of blocks field is set to a value greater than the maximum
capacity of the
> device and less than FFFFFFFFh then the command is terminated with a CHECK
CONDITION status, the sense key is set to ILLEGAL REQUEST.
> d) If the number of blocks field is set to FFFFFFFFh, the device shall be set
to its maximum
> capacity. If the block size has not changed, the device shall not become
> This capacity setting shall be retained through reset events or power cycles.
Since this change is mostly for the benefit of vendors that return zeros in the
Number of Blocks field, I hope those vendors will voice their opinion on this
change either on the reflector or at the May working group meeting.
More information about the T10