On Tue, Jan 25, 2011 at 9:23 PM, Malahal Naineni <malahal@xxxxxxxxxx> wrote:
Jun'ichi Nomura [j-nomura@xxxxxxxxxxxxx] wrote:
> >> 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.
>
> Do we really need [2]?
>
> Currently, there seem only 3 minio values in per-hardware default:
> - 1000 (DEFAULT_MINIO)
> - 128
> - 100
>
> I think both 128 and 100 are based on that, in many systems/cases,
> max request size (max_sectors) is 512KB and BIO submission
> is done in page-size unit (4KB).
>
> If there isn't strong reason for the current default (1000)
> (and I think there isn't), it seems we can remove [2]
> after changing the default to 128 (or 100).
>
> > 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.
>
> Does it mean users can't change rr_min_io value for request-based dm?
> I suspect it is possible that someone wants to set non-default
> value to minio for request-based dm.
Your reading is correct that my proposal doesn't allow it. If we get away
with [2] above (hwatable.c based values), then we can have something
like this:
1. Remove it from hwentry structure or set it to -1
2. If rr_minio is specified in the conf file (either through default or
device section etc), use it.
3. If not specified in the config file, use DEFAULT_BIO_MINIO or
DEFAULT_REQUEST_MINIO based on the multipath module version.
In other words, every device out there uses DEFAULT_BIO_MINIO or
DEFAULT_REQUEST_MINIO if not specified by the administrator.
Admin can override it in /etc/multipath.conf file.
CON: No per device controller default (aka hwtable entry value)
Thanks, Malahal.
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
hello all,
There is one doubt regarding the dm-raid1. As far as i know, in dm-raid1 the data is written parallelly on all the mirrors of mirrorset and if any of the mirror fails to write the data then dm-mirror adds this mirror to fail list by increasing the error count in "fail mirror" function in dm-raid1.
Actually my doubt is where this error count is decremented? i.e after kcpyd or before and where exactly this error count is decremented?
Regards,
Nishant.
-- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
