Programmable capacity revisited

[Gerry Houlder]

* 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 
field).

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 
mode page.

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 
field, then
  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 
behavior is
>  vendor specific.

  b) If the number of blocks is greater than zero and less than or equal to its 
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. This 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 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 
format corrupted.
> 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.