<div class="gmail_quote">On Wed, Jan 26, 2011 at 12:27 PM, nishant mungse <<a href="mailto:nishantmungse@gmail.com">nishantmungse@gmail.com</a>> wrote: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <div><div></div><div class="h5"> <div class="gmail_quote">On Tue, Jan 25, 2011 at 9:23 PM, Malahal Naineni <<a href="mailto:malahal@us.ibm.com" target="_blank">malahal@us.ibm.com</a>> wrote: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Jun'ichi Nomura [<a href="mailto:j-nomura@ce.jp.nec.com" target="_blank">j-nomura@ce.jp.nec.com</a>] 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 <a href="mailto:dm-devel@redhat.com" target="_blank">dm-devel@redhat.com</a> <a href="https://www.redhat.com/mailman/listinfo/dm-devel" target="_blank">https://www.redhat.com/mailman/listinfo/dm-devel</a> </blockquote></div> </div></div>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. </blockquote><div> 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. </div></div>