Re: [PATCH 0/3][RESEND]multipath-tools: mpathpersist utility for managing persistent reservation on dm multipath device.

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

 



On January 24, 2012, Fil Wrote:
>
>1. Patches apply against the 63704387009443bdb37d9deaaafa9ab121d45bfb
>without any problems. Everything builds correctly (tested it on centos
>6.2 and fedora 16).
>
>2. multipathd runs correctly.
>

Fil, Thanks for the update. Good to know.

>3. mpathpersist is missing --no-inquiry option. It would be nice to be
>compatible with  sg_persist. (breaks most of my test scripts.)
>
>4. mpathpersist -d /dev/mapper/blah --in --read-status
>mpathpersist: unrecognized option '--read-status'
>unrecognised switch code 0x3f ??
>

There is a typo in usage output. Please use --read-full-status instead. I will correct it. 

>5. registration works
>
>6. reservation, reserves only a single path. (is this by design?)

Yes, this is as per design. Reservation is sent to one of the active 
path and reservation is applicable to registered I_T nexus with respect to pr type.

I was expecting your device server to  apply reservation to all the 
registered I_T nexus for pr type "Exclusive Access, all registrants". Can you verify the below output again?

Please see below in SPC4
"For a persistent reservation of the type Write Exclusive – All Registrants or Exclusive Access – All Registrants,
the persistent reservation holder is any registered I_T nexus;" 

>mpathpersist --out --reserve --param-rk=123abc --prout-type=8 -d
>/dev/mapper/blah
>
>sg_persist -i -s /dev/mapper/blah
>  QNAP      iSCSI Storage     3.1
>  Peripheral device type: disk
>  PR generation=0x8
>    Key=0x123abc
>      All target ports bit clear
>      Relative port address: 0x1
>      not reservation holder
>      Transport Id of initiator:
>        iSCSI name and session id: iqn.2009-
>11.com.adriaticsolutions:blah
>    Key=0x123abc
>      All target ports bit clear
>      Relative port address: 0x1
>      << Reservation holder >>
>      scope: LU_SCOPE,  type: Exclusive Access, all registrants
>      Transport Id of initiator:
>        iSCSI name and session id: iqn.2009-
>11.com.adriaticsolutions:blah
>
>multipath -ll
>blah (36001405c55fc03cd8193d491eda0d4d7) dm-4 QNAP,iSCSI Storage
>size=10G features='0' hwhandler='0' wp=rw
>`-+- policy='round-robin 0' prio=1 status=active
>  |- 16:0:0:0 sda 8:0  active ready  running
>  `- 17:0:0:0 sdb 8:16 failed faulty running
>
>7. mpathpersist -d /dev/mapper/blah --in --read-reservation
>Persistent Reserve IN command failed
>
Can you please share the output with verbose 3. Append '-v3'.

>8. release 'fails' because reservation registered only a single path and
>the other one is in a failed state.
>
>mpathpersist -d /dev/mapper/blah --out --release --param-rk=123abc
>--prout-type=8
>Jan 24 00:43:53 | 36001405c55fc03cd8193d491eda0d4d7: pr in read
>reservation command failed.
>PR out: command failed
>
As per design, release service action performs following steps: 
Step 1) PROUT 'release' SA is sent on the all paths of the multipath device as it is not clear which data path is reservation holder.
STEP 2) PRIN read reservation SA is sent to one of the active path to verify the reservation.
STEP 3) If the Read Reservation parameter data indicates that the logical unit is still reserved then this indicates that the reservation holder belongs to a data path in failed state or removed data path of the multipath device, continue else goto step 7
STEP 4) PRIN Report Full Status  service action is issued to any active data path. Full status descriptors are saved.
STEP 5) PROUT clear reservation service action is sent via any active data path to clear the reservation and
Registrants
STEP 6) all registrants are restored by issuing PROUT register service action with transport IDs from the full status
descriptors saved in the step 4
STEP 7) exit with status

It looks like you are getting into some other issue. Can you please share the output with verbose with '-v3'.

>9. de-registration works....
>
>I haven't had time to test path fail over and weird cases when multiple
>nodes try to do destructive things to the shared luns...
>
>thanks
>fil
>
>On 01/23/2012 11:09 PM, Chauhan, Vijay wrote:
>> Thanks for these info Fil.  Can you please also share your feedback on
>your in-depth testing.
>>
>> I appreciate your effort.
>>
>> On January 20, 2012, Fil wrote:
>>> Thanks for the patches Vijay,
>>>
>>> I tested the new set of patches against the git repo, and it applied
>>> cleanly compiled and is running as expected. I will do more indepth
>>> testing over the weekend.

Thanks for your detailed testing.

Thanks and regards,
Vijay

--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel



[Index of Archives]     [DM Crypt]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite Discussion]     [KDE Users]     [Fedora Docs]

  Powered by Linux