Re: [PATCH v2 00/13] libmultipath: a generic multipath lib for block drivers

Re: [PATCH v2 00/13] libmultipath: a generic multipath lib for block drivers

[Sagi Grimberg]

On 28/04/2026 14:10, John Garry wrote:
> libmultipath: a generic multipath lib for block drivers

This is very nice John.

>
> This series introduces libmultipath. It is essentially a refactoring of
> NVME multipath support, so we can have a common library to also support
> native SCSI multipath.
>
> Much of the code is taken directly from the NVMe multipath code. However,
> NVMe specifics are removed. A template structure is provided so the driver
> may provide callbacks for driver specifics, like ANA support for NVMe.
>
> Important new structures introduced include:
>
> - mpath_head
> These contain much of the multipath-specific functionality from
> nvme_ns_head, including a pointer to the gendisk structure and
> a path SRCU-based array.

I think it should be placed first in its parent struct as it holds the 
hot-path
head->srcu and head->list.

>
> - mpath_device
> This is the per-path structure, and contains much the same
> multipath-specific functionality in nvme_ns
>
> libmultipath provides functionality for path management, path selection,
> data path, and failover handling.
>
> Since the NVMe driver has some code in the sysfs and ioctl handling
> which iterate all multipath NSes, functions like mpath_call_for_device()
> are added to do the same per-path iteration.

very nice, overall seems fairly straight forward.

Re: [PATCH v2 00/13] libmultipath: a generic multipath lib for block drivers

[John Garry]

On 10/05/2026 23:03, Sagi Grimberg wrote:
>> Important new structures introduced include:
>>
>> - mpath_head
>> These contain much of the multipath-specific functionality from
>> nvme_ns_head, including a pointer to the gendisk structure and
>> a path SRCU-based array.
> 
> I think it should be placed first in its parent struct as it holds the 
> hot-path
> head->srcu and head->list.
>

Yeah, I did originally try this. However it becomes a pain for managing 
the lifecycle of the mpath_head and nvme_ns_head/scsi_mpath_head 
structures, especially for the scenarios like the delayed head removal.

However I can see again if I can make it work.

>>
>> - mpath_device
>> This is the per-path structure, and contains much the same
>> multipath-specific functionality in nvme_ns
>>
>> libmultipath provides functionality for path management, path selection,
>> data path, and failover handling.
>>
>> Since the NVMe driver has some code in the sysfs and ioctl handling
>> which iterate all multipath NSes, functions like mpath_call_for_device()
>> are added to do the same per-path iteration.
> 
> very nice, overall seems fairly straight forward.

thanks a lot