[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: [dm-devel] multipath: change the DEFAULT_MINIO for the request based multipath
- From: Christophe Varoqui <christophe varoqui gmail com>
- To: Mike Snitzer <snitzer redhat com>
- Cc: device-mapper development <dm-devel redhat com>
- Subject: Re: [dm-devel] multipath: change the DEFAULT_MINIO for the request based multipath
- Date: Fri, 21 Jan 2011 15:46:33 +0100
> 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 ?
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]