On Thu, Feb 16 2017 at 1:07pm -0500, Keith Busch <keith.busch@xxxxxxxxx> wrote: > On Thu, Feb 16, 2017 at 05:37:41PM +0000, Bart Van Assche wrote: > > On Thu, 2017-02-16 at 12:38 -0500, Keith Busch wrote: > > > Maybe I'm not seeing the bigger picture. Is there some part to multipath > > > that the kernel is not in a better position to handle? > > > > Does this mean that the code to parse /etc/multipath.conf will be moved into > > the kernel? Or will we lose the ability to configure the policies that > > /etc/multipath.conf allows to configure? > > No, I'm just considering the settings for a device that won't work > at all if multipath.conf is wrong. For example, the uuid attributes, > path priority, or path checker. These can't be considered configurable > policies if all but one of them are invalid for a specific device type. > > It shouldn't even be an option to let a user select TUR path checker > for NVMe, and the only checkers multipath-tools provide that even make > sense for NVMe are deprecated. 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.
