Christoph Hellwig <hch@xxxxxxxxxxxxx> writes: > On Tue, Dec 28, 2021 at 04:30:08PM -0500, Mike Snitzer wrote: >> Yeah, people use request-based for IO scheduling and more capable path >> selectors. Imposing bio-based would be a pretty jarring workaround for >> BLK_MQ_F_BLOCKING. request-based DM should properly support it. > > Given that nvme-tcp is the only blocking driver that has multipath > driver that driver explicitly does not intend to support dm-multipath > I'm absolutely against adding block layer cruft for this particular > use case. Maybe I have bad taste, but the patches didn't look like cruft to me. :) I'm not sure why we'd prevent users from using dm-mpath on nvmeof. I think there's agreement that the nvme native multipath implementation is the preferred way (that's the default in rhel9, even), but I don't think that's a reason to nack this patch set. Or have I missed your point entirely? Thanks! Jeff -- dm-devel mailing list dm-devel@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/dm-devel
