On Thu, Feb 16, 2017 at 01:21:29PM -0500, Mike Snitzer wrote: > Then undeprecate them. Decisions like marking a path checker deprecated > were _not_ made with NVMe in mind. They must predate NVMe. > > multipath-tools has tables that specify all the defaults for a given > target backend. NVMe will just be yet another. Yes some user _could_ > shoot themselves in the foot by overriding the proper configuration but > since when are we motivated by _not_ giving users the power to hang > themselves? > > As for configurability (chosing between N valid configs/settings): At > some point the user will want one behaviour vs another. Thinking > otherwise is just naive. Think error timeouts, etc. Any multipath > kernel implementation (which dm-multipath is BTW) will eventually find > itself at a crossroads where the underlying fabric could be tweaked in > different ways. Thinking you can just hardcode these attributes and > settings is foolish. Roger that, and I absolutely want to see this work with the existing framework. I just think it'd be easier for everyone if multipath were more like the generic block layer, in that devices are surfaced with configurable policies without userspace telling it which to use. The kernel knowing safe defaults for a particular device is probably the more common case, and userspace can still tune them as needed. Of course, I accept you're in a better position to know if this is folly.
