On 02/15/17 18:53, Mike Snitzer wrote:
Nobody has interest in Linux multipathing becoming fragmented. If every transport implemented their own multipathing the end-user would be amazingly screwed trying to keep track of all the quirks/configuration/management of each. Not saying multipath-tools is great, nor that DM multipath is god's gift. But substantiating _why_ you need this "native NVMe multipathing" would go a really long way to justifying your effort. For starters, how about you show just how much better than DM multipath this native NVMe multipathing performs? NOTE: it'd imply you put effort to making DM multipath work with NVMe.. if you've sat on that code too that'd be amazingly unfortunate/frustrating.
Another question is what your attitude is towards dm-mpath changes? Last time I posted a series of patches that significantly clean up and
improve readability of the dm-mpath code you refused to take these upstream. Bart. -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
