On 2/25/26 01:46, Benjamin Marzinski wrote:
On Sat, Feb 21, 2026 at 12:41:28PM -0500, Mike Snitzer wrote:
On Fri, Feb 13, 2026 at 02:19:11PM +0000, John Garry wrote:
At ALPSS 25 I presented a proposal for Native SCSI multipath support. Let's
discuss this topic at LSFMM.
The idea for this is that SCSI could natively support multipath, like how
NVMe host driver does today. It is intended as an alternative to
dm-multipath support.
I have been working on the implementation and I plan to post patches in the
next cycle. I am looking at a 3-stage approach:
a. create a driver-agnostic multipath library, very heavily based on NVMe
host multipath support.
The library would support features such as path management, path
selection/iopolicy, failover recovery, PR, delayed removal, gendisk
management etc.
b. switch NVMe over to use this library
I can appreciate that the kernel to userspace interface of DM
multipath is clearly unwanted (hence NVMe multipath and now SCSI
multipath).
But you should really be switching DM-multipath over to using it too;
or at least detailing _why_ the core of DM multipath
(drivers/md/dm-mpath.c) cannot be updated to use this common backend
library.
This line of work makes little sense to me if it just ignores
dm-multipath.
Mike
Thinking about this work from a DM multipath perspective, I'm more
interested in how much it plans to handle the more annoying niche cases
of dealing with SCSI devices, like paths that confidently report that
they are able to accept IO, only to fail all IO sent to them. Also, I
wonder how/if this is planning on handling Persistent Reservations. The
arrays, I assume, are still going to see this as a collection of I_T
Nexuses (some of which may be down and unable to accept commands at any
given time, and to which new ones my be added) instead of a single one.
I also think this would be useful to talk about at LSF.
And that even makes me wonder whether we should have a discussion about
persistent reservations at LSF, too.
I seem to be involved in discussions about PRs from various angles now
(live migration seems to want to join the fray), so maybe we could get
together to discuss things.
And I _still_ want to have a blktests for persistent reservations ...
Cheers,
Hannes
--
Dr. Hannes Reinecke Kernel Storage Architect
[email protected] +49 911 74053 688
SUSE Software Solutions GmbH, Frankenstr. 146, 90461 Nürnberg
HRB 36809 (AG Nürnberg), GF: I. Totev, A. McDonald, W. Knoblich
