Re: Persistent reservation behaviour/compliance with redundant controllers

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 <psychotrahe@xxxxxxxxx> wrote:
> 
> 2014/1/7 James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx>:
>>> 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 majordomo@xxxxxxxxxxxxxxx
> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]
  Powered by Linux