Persistent Reservation and Reservation Key Uniqueness/non-uniqueness

Bob Snively Bob.Snively at Eng.Sun.COM
Tue Jul 22 09:08:47 PDT 1997

* From the T10 (formerly SCSI) Reflector (t10 at, posted by:
* Bob Snively <Bob.Snively at Eng.Sun.COM>

For a particular LUN-Initiator pair, there can only be one registered 
reservation key. Note that an initiator attached to two ports is really 
two LUN-Initiator pairs.  So at least the number does not multiply times the 
number of reservations.

However,  there is no rule at present that prevents an initiator from using
a different reservation key for each LUN.  Most will tend not to, since there
is a good probability that the inspection algorithm used by hosts would like
to have only one identifier associated with each of its co-hosts ports, but
the standard does not create such a restriction, and probably should not.

I would suggest that people specify a maximum number of registrations that
can be supported by a LUN as part of their implementation specifications.
On an FC-AL RAID controller, the number may be quite large so that switches
and hubs can be supported for a large number of virtual logical units.


> * From the T10 (formerly SCSI) Reflector (t10 at, posted by:
> * "Steve Sicola...Array Controller Engineering 522-2268" 
<sicola at>
> *
> Hey there..
> Just a note about Reservation keys in a multi-host, multi-adapter/host
> environment. There is no guarantee that an initiator will use the same
> reservation key when registering with multiple LUNs. The implication for this
> is the amount of memory this can mean to a controller (or even a shared disk 
> a lesser extent) that has to kept persistently. Certainly it can be kept on 
> disk, however, a good number of implementations may use some kind of 
> non-volatile memory.
> It would seem that two problems may exist here. The first being that for
> multiple hosts that will have different reservation keys. This problem can be
> alleviated by individual hosts using a single key for reserving LUNs for
> itself. The second problem is that of multiple adapters per host, where the
> potential for lots of different keys per adapter/host/LUN can explode the
> information being kept and precludes clever compression of the reservation key
> table. 
> I am sure Tom Coughlan has brought this up before at the Working Group
> meetings, however, I'd like to know what people think about this and whether
> or not there is real merit from allowing unique keys per
> reservation/adapter/LUN...

* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at

More information about the T10 mailing list