2014/1/7 James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx>
>
> On Mon, 2014-01-06 at 23:53 +0100, Matthias Eble wrote:
> > 2014/1/6 Lee Duncan <lduncan@xxxxxxxx>:
> > > On 12/25/2013 03:00 PM, Matthias Eble wrote:
> > >> Here's the dmmp map
> > >> 360002ac0000000000000000a00006e6b dm-6 3PARdata,VV
> > >> size=2.0T features='0' hwhandler='0' wp=rw
> > >> `-+- policy='round-robin 0' prio=1 status=active
> > >> |- 3:0:1:4 sdg 8:96 active ready running
> > >> |- 3:0:3:4 sdl 8:176 active ready running
> > >> |- 5:0:3:4 sdbg 67:160 active ready running
> > >> `- 5:0:1:4 sdce 69:32 active ready running
> > >>
> > >> There can only be two registrations at a time: (sdg XOR sdl) and (sdbg XOR sdce)
> > >> Now my question is: Does this comply to the standard?
> > >>
> > >
> > > I _believe_ the problem is that you are re-registering the same
> > > I_T_Nexus through /dev/sdl, your second attempt at registration, as you
> > > did when you used /dev/sdg, your original registration.
> >
> >
> > 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.
Hi All,
I'd like to document the progress and findings in lots of off-list emails with
HP's t10 members.
Maybe someone on the net will face the same problem.
First of all, the SPC wording isn't 100% precise. For most commands, the Lun
context is implicit. So if the standards state "I_T Nexus", I_T_L Nexuses are
meant, as the reservation commands are always lun specific.
That said, PR-registrations need to be done for every
I_T_L Nexus -> every single dmmp path (/dev/sdX)
So we started to test the behaviour of the 3Par system.
It seems that there are some quirks in the 3Par implementation.
The error that led to my initial question is that the target port
identifier isn't included in the target's reservation handling.
Thus all PR commands from one host port are considered the same.
Regardless of the target port over which they were received.
(As seen in attached commands #5 or #6 after issuing #2 )
Note that the investigations haven't been finished.
For those who are interested, here are the findings (verbose output stripped):
1.# sg_persist --in --read-keys /dev/sdl
3PARdata VV 3122
Peripheral device type: disk
PR generation=0x44, there are NO registered reservation keys
register via sdl:
2.# sg_persist -vvv -d /dev/sdl --no-inquiry --out --register
--param-sark=0x420480a02900006c
PR out: command (Register) successful
test for scp3r23 table 33 compliance (same key on registered I_T Nexus
should succeed): False
3.# sg_persist -vvv -d /dev/sdl --no-inquiry --out --register
--param-sark=0x420480a02900006c
persistent reserve out: scsi status: Reservation Conflict
PR out: command failed
now with a *different key* (should conflict): True
4.# sg_persist -vvv -d /dev/sdl --no-inquiry --out --register
--param-sark=0x420480a02900006d
persistent reserve out: scsi status: Reservation Conflict
PR out: command failed
Same behaviour using another path/I_T_L Nexus (should succeed in both cases):
5.# sg_persist -vvv -d /dev/sdg --no-inquiry --out --register
--param-sark=0x420480a02900006c
persistent reserve out: scsi status: Reservation Conflict
PR out: command failed
6.# sg_persist -vvv -d /dev/sdg --no-inquiry --out --register
--param-sark=0x420480a02900006d
persistent reserve out: scsi status: Reservation Conflict
PR out: command failed
Unregister via sdg :-/
7.# sg_persist -vvv -d /dev/sdg --no-inquiry --out --register
--param-rk=0x420480a02900006c
PR out: command (Register) successful
Additionally, read-full-status service action and ALL_TG_PT are not
supported, right now.
That's it for now.
Thanks for your replies,
Matthias
--
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
