Hi Christoph,

On 2017/10/28 14:38, Christoph Hellwig wrote:

On Tue, Oct 24, 2017 at 05:40:00PM -0400, Mike Snitzer wrote:

quoted

Having the NVme driver go to such lengths to hide its resources from
upper layers is certainly the work of an evil genius experiencing some
serious territorial issues.  Not sugar-coating it.. you wouldn't.

I'm pretty surre Hannes will appreciate being called an evil genius :)

quoted

I kept meaning to reply to your earlier iterations on this series to
ask: can we please get a CONFIG_NVME_MULTIPATHING knob to make it so
that the NVMe driver doesn't implicitly consume (and hide) all
per-controler devices?

I thought about adding it, but mostly for a different reason: it's
quite a bit of code, and we now start to see NVMe in deeply embedded
contexts, e.g. the latest Compact Flash spec is based on NVMe, so it
might be a good idea to give people a chance to avoid the overhead.

Think of some current advanced features of DM-Multipath combined with multipath-tools
such as path-latency priority grouping, intermittent IO error accounting for path
degradation, delayed or immediate or follow-over failback feature.
Those features, which is significant in some scenario, need to use per-controller block devices.
Therefore, I think it is worthy adding a CONFIG_NVME_MULTIPATHING knob to
hide or show per-controller block devices.

How about let me to add this this CONFIG_NVME_MULTIPATHING knob?

Regards
Guan

quoted

Ah well.  There is only one correct way to do NVMe multipathing after
all right?

I don't think you'll get very useful results, even if you try.  But I
guess we'll just have to tell people to use SuSE if they want NVMe
multipathing to work then :)

_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme