On 7/14/22 1:49 PM, Mike Snitzer wrote: > On Sat, Jul 09 2022 at 11:06P -0400, > Mike Christie <michael.christie@xxxxxxxxxx> 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. -- dm-devel mailing list dm-devel@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/dm-devel
