Multi-LUN feature of Set Capacity proposal
Gerry Houlder
Gerry_Houlder at notes.seagate.com
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,
however.
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