Multi-LUN feature of Set Capacity proposal

Gerry Houlder Gerry_Houlder at
Thu Aug 17 09:44:45 PDT 1995

Some good questions were raised by Jeff Stai and Jim McGrath about splitting 
capacity among several LUNs. I need to better describe my views on this.

First, I want to state that supporting the multiple LUN feature is OPTIONAL, 
even for a target that chooses to support the Set Capacity feature. The 
complexity of separate command queues, sense data, unit attention reporting, 
etc. for each LUN makes this into a major undertaking (compared to only 
supporting LUN 0). This is what we refer to in the committee as "Major 
Optionality". A standards document is typically very loose about this, and I 
hope the absence of the word "mandatory" is enough to imply that all of the 
major pieces are independently optional.

Jeff suggested this wording change about the meaning of LBA=0 and LUN=0:
"If the LUN is zero, a value of zero in the logical block address field
indicates that all other logical units shall become unsupported, and
that this logical unit shall be assigned all of the capacity."

I didn't envision the destruction of all other LUNs by this action. I thought 
it would be safer to only destroy a LUN with a Set Capacity command 
specifically sent to that LUN. Now that Jeff has suggested it, however, this 
feature would certainly make it easier to reconfigure a drive back to one LUN. 
If the initiator really wanted LUN 0 to get bigger without destroying the other 
LUNs, it could just use an LBA=0xFFFFFFFF. I will incorporate Jeff's suggestion 
unless others object.

Jeff also asked what would happen with an "old fashioned" controller with 4 
LUNs attached. As far as I am concerned, that configuration would follow the 
rules of a SCC device rather than an SBC device, so this feature doesn't apply.

Jim raised several questions about creating and destroying LUNs in particular 
order. I will go through an example with a 10 GB drive that adds the detail Jim 
is asking for. I have no idea how to specify all this stuff in the standard, 

1) A set capacity is issued to LUN 0, setting its capacity at 4 GB. At this 
point, the remaining capacity (6 GB) is not assigned to any LUN and is not 
addressable by any LUN. Attempts to address more than 4 GB capacity from LUN 0 
should result in CHECK status, SK=Illegal Request, ASC=LBA out of range. This 
is the same result for a drive that will allow creation of new LUNs or for a 
drive that won't.

2) A set capacity is issued to LUN 2. I believe this should be rejected because 
LUN 1 doesn't exist. I think we should require LUNs to be created in ascending 
order to follow past SCSI practice. Should the sense bytes be "illegal LUN" (my 
preference, since this is backwards compatible with devices that don't support 
this feature) or "Illegal Request"? The illegal request response has the 
advantage of differentiating a drive that does support multiple LUNs from a 
drive that won't.

3) A set capacity is issued to LUN 1, setting its capacity at 4 GB. This 
command should only be accepted if the drive supports splitting into multiple 
LUNs AND there is capacity available that hasn't been assigned to other LUNs. 
If the command is rejected, the sense byte choices are the same as in case (2). 
If the command is accepted (GOOD status), the drive will have a 4 GB LUN 0, a 4 
GB LUN 1, and 2 GB that are unassigned.

4) A set capacity is issued to LUN 0, setting its capacity at 6 GB. It could be 
rejected with "Illegal Request" because the drive doesn't want to deal with 
non-contiguous LUN assignments. Should such implementation specific rules be 
allowed? The command could be accepted, resulting in a 6 GB LUN 0 and a 4 GB 
LUN 1.

5) A set capacity is issued to LUN 0, setting its capacity to 3 GB. The lowest 
address 3 GB remain in LUN 0 and LUN 1 remains at 4 GB. 3 GB are now 
unassigned. Should a unit attention be set to warn other initiators that LUN 0 
capacity has decreased? This is a potential data loss situation. Is such a unit 
attention also required if capacity is increased (as in case (4))?

Now that we are getting into the nitty gritty of handling multiple LUNs, we 
have to ask ourselves if there is a better way to do this. I still prefer 
defining a new block descriptor format for the 10 byte MODE SELECT command that 
allows for a 4 byte Number of Blocks field AND a LUN field. With this 
capability, a drive can be split into multiple LUNS by issuing a single MODE 
SELECT(10) command to LUN 0. The data phase would include multiple block 
descriptors: each descriptor would have the LUN (1 byte is enough - this is a 
block device not a SCC device), Number of Blocks field (4 bytes), and Block 
Size field (3 bytes). Perhaps the descriptors should be 12 bytes each, so a 
block descriptor type field or other fields can also be included.

The target can deal with the entire request at one time -- allocating space for 
each LUN, making the space contiguous within each LUN, forcing the LUNs to be 
numbered in ascending order, rejecting the request if multiple LUNs aren't 
supported, shortening the last LUN if too much capacity is being asked for, 
etc. This bypasses a lot of problems that arise with a set capacity that only 
deals with one LUN at a time. The problems with reservations that were pointed 
out by Milton's message also seem to be easier to handle with this technique. 
There is one disadvantage: resizing any LUN will probably result in address 
space shifting in the other LUNs also. This means more opportunity to shuffle 
customer data around if this is done on line.

More information about the T10 mailing list