> I'm not following why we'd need a different configuration parameter. > It is just that the default rr_min_io that would be used would be > conditional on the multipath target version being >= 1.1.0. > Defaults are layered. For current minio, we have : [1] one top level default (hardcoded, superseded by config) [2] per hardware default (hardcoded, superseded by config) [3] per multipath value (none hardcoded, defined by config) You suggest multipath-tools to adapt only the top level minio default depending on dm-rq availability [1], but what of the hwtable defaults [2] ? Should we provide vendors with a way to describe a with-rq minio default *and* a without-rq minio default (a new parameter in the hwentry struct) ? If so, we should also provide a new config file keyword to override this new hwentry parameter hardcoded value ... then the reasoning cascades to the mpentry struct minio setting [3]. Actually, [1] is hardly the common case : only unknown hardware resort to these defaults. Is my reasoning flawed ? -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
