From mboxrd@z Thu Jan 1 00:00:00 1970 From: Malahal Naineni Subject: Re: multipath: change the DEFAULT_MINIO for the request based multipath Date: Fri, 21 Jan 2011 09:39:30 -0800 Message-ID: <20110121173930.GB20278@us.ibm.com> References: <91d6dae7d88296d8a1fe.1295472607@malahal> <4D37E513.3070506@suse.de> <20110120160726.GA23529@redhat.com> <4D392FBD.5080207@ce.jp.nec.com> <1295599627.23625.16.camel@zezette> <20110121141204.GE30411@redhat.com> <1295621193.23625.37.camel@zezette> Reply-To: device-mapper development Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <1295621193.23625.37.camel@zezette> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com To: dm-devel@redhat.com List-Id: dm-devel.ids Christophe Varoqui [christophe.varoqui@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.