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

[Mike Christie]

On 7/18/22 12:55 AM, Christoph Hellwig wrote:
> On Thu, Jul 14, 2022 at 07:34:57PM -0500, Mike Christie wrote:
>> 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).
> 
> Why would any reservation type make less sense for multipath vs
> non-multipath setups/

I think those 2 types only work for really specific use cases in multipath
setups.

1. Let's say you do an active-active setup with 2 paths in one priority group,
and the Write Exclusive or Exclusive Access reservation went down pathA so it's
the holder. When the app does IO to /dev/dm-0 the path selectors aren't PGR aware
so IO can go down any path. For Write Exclusive, when WRITEs go down pathB they
get failed with reservation conflicts (sbc4r22 table 13). So this type of
reservation and active-active would only be useful for read-only work loads.

For Exclusive Access READ/WRITEs can only go down pathA ok. If they go down
PathB we will get reservation conflicts. So it's really useless in an active-
active setup.

For All Reg and Reg Only this is not a problem because all paths are registered
and the spec says for those types of reservations we can do R/W IO through them
(sbc4r22 table 13).

2. For an active-passive setup with 2 priority groups and 1 path per group we have
a similar issue when there is a path failure. PathA in PG0 will be the holder and
since we have the one path in use, all IO will execute ok. If pathA fails and we
switch to pathB in PG1, then similar to above, depending on the reservation type
and IO type, we will get conflicts since PathA was the holder.

I was thinking maybe for this one, some specific user sometimes wants this
behavior (use PG1 as a last resort). However, I think the user would normally
expect the All Reg or Reg only behavior where when we switch to pathB and don't get
conflicts for a path failure.

For a non-multipath setup we don't hit 1 or 2 with Write Exclusive or Exclusive
Access since each host just has the one path to the device.

>>
>>
>>> 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.
> 
> Well.  In general ALL_TG_PT would usually be the preferred method
> everywhere.  But that assumes:
> 
>  1) it actually is supported by the target
>  2) the target actually has a useful concept of the Linux system being
>     a single initiator, which outside of a few setups like software
>     only iSCSI are rarely true
> 
> so we usually have to fall back to just registering every path
> separately.

Yeah, windows sends a register down each path like us too.