[dm-devel] multipath: change the DEFAULT_MINIO for the request based multipath

nishant mungse nishantmungse at gmail.com
Wed Jan 26 17:27:43 UTC 2011


On Tue, Jan 25, 2011 at 9:23 PM, Malahal Naineni <malahal at us.ibm.com> wrote:

> Jun'ichi Nomura [j-nomura at ce.jp.nec.com] 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 at redhat.com
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/dm-devel/attachments/20110126/e9c9d5a0/attachment.htm>


More information about the dm-devel mailing list