On 11/9/24 05:45, himanshu.madhani@xxxxxxxxxx wrote:
From: Himanshu Madhani <himanshu.madhani@xxxxxxxxxx>
Hello Folks,
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.
First of all, thank you for doing this.
Had been on my to-do list for a long time.
However, the one crucial thing why I kept pushing it back is:
Residuals.
NVMe native multipathing works because NVMe is a 'all-or-nothing'
protocol, ie either the entire I/O had been completed, or nothing has
happened.
Which means for any failure we can safely retry the entire I/O on a
different path (that's the 'steal_bio' thingie), knowing that it's safe
to do so.
For SCSI, however, this is not the case; it's perfectly valid for a
target to do a partial completion, and ask the initiator to retry the
remainders. And this partial completion might be at any position within
the bvec, requiring us to resend the bio from a random starting position.
Meaning we cannot do a blind 'steal_bio' thing.
So: have you evaluated you series wrt to residuals?
Have you _measured_ if residuals are happening?
Have you considered your patchset how residuals could be
treated?
(It _might_ be possible to resend the entire I/O over to another path,
even if the command had been partially completed. That's perfectly safe
for reads, but for writes you have to be extremely careful to not cause
a data corruption. We had some fun discussions here over at the NVMe
side ...)
And: please drop the device handler thingie for this, and concentrate
on ALUA. No point in carrying legacy stuff around.
_AND_ you have to evaluate the ALUA settings anyway to get a decent
path selection.
Cheers,
Hannes
--
Dr. Hannes Reinecke Kernel Storage Architect
hare@xxxxxxx +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
