[dm-devel] multipath: change the DEFAULT_MINIO for the request based multipath
Malahal Naineni
malahal at us.ibm.com
Fri Jan 21 17:39:30 UTC 2011
Christophe Varoqui [christophe.varoqui at gmail.com] wrote:
>
> > 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 ?
I don't think so. Your reasoning is right. How about this:
1. Set DEFAULT_MINIO to -1
2. If bio based mapping and the value is -1, set it to 1000
(DEFAULT_BIO_MINIO)
3. If request based mapping, set it to DEFAULT_REQUEST_MINIO.
Note that devices can't have individual hardware default for request
based mappings in this method and I think that should be OK. They are
allowed to individual hardware based default for BIO based mappings as
they have now. I will code it up if everyone agrees.
Thanks, Malahal.
More information about the dm-devel
mailing list