Milton's comments on Set Capacity proposal

Gerry Houlder Gerry_Houlder at notes.seagate.com
Wed Aug 16 13:40:34 PDT 1995


These are my responses to Milton's questions:

>I'm not all that familiar with SCSI-3 yet, but is there a way for an
>initiator to reserve a whole device with one command in SCSI-3, regardless
>of the number of LUNs?

No. In SCSI-3 reservations are still on a "per LUN" basis.

>It seems to me that this command is one which will be protected by a
>reserve/release by the initiator doing the changes. If reserve/release is
>done on a LUN basis and the set capacity command creates/destroys LUNs, I
>see the potential for conflicts. When a LUN becomes unsupported by this
>command, would a reservation on this LUN automatically disappear? When a LUN
>becomes supported, would there a reservation created for it? You really want
>one somehow, and having to issue another reserve for a new LUN leaves a
>small window where another initiator can get in.

The wording I have added on "reservation behavior" will prevent an initiator 
from
changing the capacity (including destroying it altogether) of an existing LUN 
that
has any kind of a reservation in effect for another initiator. I don't 
anticipate the need
to reserve a LUN before changing its capacity. I hope multi-initiator systems 
would
mark a drive as being "off line" (and therefore not accessed by any other 
initiator)
before changing the capacity of a LUN.

Clearly a reservation cannot be made to an unsupported LUN, so "creating" a new
LUN must always be done without having a reservation in effect and I see no need
to "create" a reservation when the LUN is created. After all, why would other 
initiators
be cruising around accessing what they think is a non-existent LUN?

We DO need to talk about whether to do an automatic release if a reservation is 
in
effect to the initator issuing the Set Capacity command. When the set capacity
destroys a LUN, a future release would get rejected with CHECK status, 
unsupported
LUN sense bytes.

> In general, an initiator
>will want to reserve all current LUNs on a device before setting new
>capacities, and if there is more than one LUN on a device initially you can
>see the potential for deadlocks when multiple initiators try to reserve all
>the LUNs on a device. Perhaps there should be a requirement that the drive
>return ILLEGAL REQUEST when all of its current LUNs are not reserved by the
>same initiator, and that any LUNs activated during this process have an
>implicit reservation (but this would be a rather vague requirement that I
>don't really like).

Like many other SCSI features, there is a potential for misuse in a 
multi-initiator
emvironment. However, I don't like linking the action of this command to the
existence of multiple reservations. I also don't like creating a reservation by
the act of creating a LUN. The system should manage this by taking the
drive "off line" in order to change capacity assigned to any LUN.

>Also, shouldn't the device generate a UNIT ATTENTION with appropriate
>status after this is done to alert all initiators of the changes?

Maybe. Such a unit attention could alert other initators to re-initialize their 
drive
mapping tables. Would an initiator actually be able to do this without 
rebooting?
This also needs to be discussed a lot more. If the drive is off line when the 
change happens, the act of putting it back "on line" will take care of 
initializing
the system's drive mapping tables. The Unit Attention could be a good warning
mechanism that a drive has been inappropriately changed while it is still on 
line.




More information about the T10 mailing list