Hi Bart,
On 11/10/24 13:15, Bart Van Assche wrote:
On 11/8/24 8:45 PM, himanshu.madhani@xxxxxxxxxx wrote:
Here is a very early RFC for multipath support in the scsi layer. This
patch series
implements native multipath support for scsi disks devices.
In this series, I am providing conceptual changes which still needs
work. However,
I wanted to get this RFC out to get community feedback on the
direction of changes.
This RFC follows NVMe multipath implementation closely for SCSI
multipath. Currently,
SCSI multipath only supports disk devices which advertises ALUA
(Asymmetric Logical
Unit Access) capability in the Inquiry response data.
Something very important is missing from the cover letter, namely a
motivation of why this initiative has been started. Why to add native
multipath support to the SCSI core instead of using dm-multipath? Isn't
one of the goals of the Linux kernel not to duplicate functionality that
already exists? How does the new infrastructure compare with
dm-multipath from the point of view of performance and functionality?
Sorry about missing motivation section in the cover letter. I'll add
that in v2 when I am ready to send an updated version of this RFC.
Here's motivation
1. Having native multipath provides a seamless configuration and setting
of multipath with SCSI, which does not involve any other dependencies.
Especially discovery and assembly of raid array. My motivation with
native SCSI multipath is to avoid having any 3rd party daemon to do the
discovery and assembly of multipath devices, which can sometimes create
issues if devices are not discovered properly. The implementation of
native multipath will avoid all that additional steps and by virtue will
provide plug-n-play capability for SCSI multipath configurations. Also,
having native support will help modernize SCSI code with respect to
multipath support and provide tighter integration for SCSI stack.
2. On the performance point of view, I believe that switching to RCU
based path selection logic will provide faster path fail-over and will
improve overall IO latency. In this RFC, I have not spent time on
performance collection. I am hoping to provide more comprehensive data
with the next RFC update.
I do not believe this is duplication of functionality since I am
providing in-kernel multipath option which will provide users a choice
of using native v/s out of kernel multipath implementation based on
their needs.
Thanks,
Bart.
--
Himanshu Madhani Oracle Linux Engineering
