I reached out to a. Contact at HP and he shared this with. Not sure if its 
helpful.

3PAR does something different based on the host OS mode or Persona that is set 
for the host OS type being used as to how we respond with these commands. The  
main aspects of this question derive with how a active/passive controller model 
would work, however, because 3PAR is all controllers or nodes are equal all 
paths are active. The 3Par implementation of S2R and S3PGR is intended to 
comply with SPC-3. The scope of reservations is limited to a full logical unit, 
element scope is not supported. SCSI-3 reservations allow each host/array path 
to have a key registered against it. Typically a host will register the same 
key upon all of the paths it sees to the array and each host will have its own 
unique key. Access to the volume can then be restricted to those hosts who have 
registered keys. Should a host be determined to have gone rogue its key can be 
revoked by any of the still active hosts, causing the rogue host to lose access 
to the volume.
 
They need to register the same key to all paths of the same lun.
 
Once the host has taken appropriate action to become healthy again it can 
register a new key and regain access.
 
For 3PAR use the showrsv command to view things from the 3PAR array:
 
showrsv - Show information about scsi reservations of virtual volumes (VVs).
 
SYNTAX
    showrsv [options <arg>] [<VV_name>]
 
DESCRIPTION
    The showrsv command displays SCSI reservation and registration information
    for VLUNs bound for a specified port.
 
AUTHORITY
    Any role in the system
 
OPTIONS
    -l <scsi3|scsi2>

> On Jan 6, 2014, at 6:35 PM, Matthias Eble <psychotr...@gmail.com> wrote:
> 
> 2014/1/7 James Bottomley <james.bottom...@hansenpartnership.com>:
>>> On Mon, 2014-01-06 at 23:53 +0100, Matthias Eble wrote:
>>> 
>>> Can sdg and sdl be the same I_T_Nexus at a time?
>>> Right now, they are handled like that.
>>> In my understanding, every scsi disk device represents an I_T_Nexus.
>> 
>> No, every SCSI disk is an I_T_L nexus.  There's no actual device object
>> in Linux for an I_T nexus.
> 
> So, PR registrations are made for an I_T nexus using an I_T_L nexus.
> Probably my previous systems had a 1:1 relation between I_T and I_T_L.
> 
> Is there a way to identify which I_T_L nexuses belong to the same I_T nexus?
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to