[dm-devel] [PATCH 2/3] dm: Start pr_reserve from the same starting path

[Mike Christie]

On 7/14/22 1:49 PM, Mike Snitzer wrote:
> On Sat, Jul 09 2022 at 11:06P -0400,
> Mike Christie <michael.christie at oracle.com> wrote:
> 
>> On 7/7/22 3:27 PM, Mike Christie wrote:
>>> When an app does a pr_reserve it will go to whatever path we happen to
>>> be using at the time. This can result in errors where the app does a
>>> second pr_reserve call and expects success but gets a failure becuase
>>> the reserve is not done on the holder's path. This patch has us always
>>> start trying to do reserves from the first path in the first group.
>>>
>>
>> Hi,
>>
>> Giving myself a review comment. pr_preempt can also establish a reservation.
>> I meant to send a patch for that as well. If the approach in this patchset is
>> ok, I'll send a patch for that as well.
>>
> 
> It'd be nice to have Christoph weigh-in on these changes but I'm OK
> with them in general.
> 
> But please give details on what you've tested them against.  I assume
> the Windows cluster? How about pacemaker? And all looks good on other

Yeah, I tested with windows clustering. With the patches we pass its
validation test suite.

I did not run pacemaker. I was reviewing their scsi/multipath fence
agents and noticed they use a Registrants Only reservation like windows.
I just ran the commands they run manually. It works ok with the preempt
change I mentioned I forgot above.

I also ran the libiscsi PGR tests. We pass all of those tests except the
Write Exclusive and Exclusive Access tests. I don't think those reservation
types make sense for multipath devices though. And as I write this I'm
thinking we should add a check for these types and just return failure).


> systems that don't have the requirement to pin the PR to a device?

I didn't find any real applications that use the All Registrants type of
reservation where every registered path is a reservation holder. However,
libiscsi has PGR tests for that type of reservation and the code works ok.

> 
> Once I have this context on testing I can then work through the
> changes more closely and get them staged.  Please do feel free to send
> a v2 that conveys what testing was done and you're welcome to sned the
> patch for pr_preempt too.
> 

Ok. I'll send an updated patchset and add more details about what I tested
in the commits so we have it in there.