Re: multipath: change the DEFAULT_MINIO for the request based multipath

[nishant mungse <nishantmungse@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 4228 bytes --]

On Wed, Jan 26, 2011 at 12:27 PM, nishant mungse <nishantmungse@gmail.com>wrote:

>
>
> On Tue, Jan 25, 2011 at 9:23 PM, Malahal Naineni <malahal@us.ibm.com>wrote:
>
>> Jun'ichi Nomura [j-nomura@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@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.
>



Hi,

I've created a device mapper target and I wanna test its read and
write mechanisms. I created a device using this target and tried to
write a filesystem on to the device.

My target is creating roughly two outgoing bios per incoming bio.
Which is maybe why I'm not able to get a proper log after running the
mke2fs command as while writing the filesystem, there are massive
amounts of writes performed on the device.

So, I tried to use the cat command to directly write to the device
file. The write is being performed for sure because I'm able to view
the data written to the underlying device.

But there is no output when I try to read the device file contents using
cat.

Is there any other way to test the read/write workflows of a dm target
that can give out a proper log ?

Regards,
Nishant.

[-- Attachment #1.2: Type: text/html, Size: 5547 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]