Date: Tue, 28 Apr 2009 20:30:08 +0200 From: Ivan Voras <ivoras@freebsd.org> To: freebsd-current@freebsd.org Subject: Re: Improving geom_mirror(4)'s read balancing Message-ID: <gt7i03$eov$1@ger.gmane.org> In-Reply-To: <49F6DA03.2010404@FreeBSD.org> References: <49F6CA67.6030302@FreeBSD.org> <gt6j7e$r6n$1@ger.gmane.org> <49F6DA03.2010404@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD8A6AFEB1FFA72A04307253B Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Maxim Sobolev wrote: > Ivan Voras wrote: >> Maxim Sobolev wrote: >> >>> The patch is available here: >>> http://sobomax.sippysoft.com/~sobomax/geom_mirror.diff. I would like = to >>> get input on the functionality/code itself, as well on what is the be= st >>> way to add this functionality. Right now, it's part of the round-robi= n >>> balancing code. Technically, it could be added as a separate new >>> balancing method, but for the reasons outlined above I really doubt >>> having "pure" round-robin has any practical value now. The only case >>> where previous behavior might be beneficial is with solid-state/RAM >>> disks where there is virtually no seek time, so that by reading close= >>> sectors from two separate disks one could actually get a better speed= =2E >>> At the very least, the new method should become default, while "old >>> round-robin" be another option with clearly documented shortcomings. = I >>> would really like to hear what people think about that. >> >> Have you perhaps seen this: >> >> http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/113885 >> >> I'm using the patch in the PR and it helps a bit, similar to what you >> have seen. Pawel is silent about the issue so I guess it can also be >> taken as silent approval :) >=20 > Oh, great! I am curious as to if there is any background behind > "distance to use delay" metric?=20 I thought it's very similar to what you did - it attempts to send BIOs to the drive whose head is "closest" to the last position, but attempts to use time instead of area covered by the head. (if I'm reading it correctly). > To me it seems the current number of > outstanding requests is much more important when selecting between disk= > X and disk Y. I am not a storage expert, so that I could be wrong > though. One way or another the load-balancing has be improved and the > new more intelligent scheduling IMHO should be the default one. I agree. I currently don't have any systems on which I could test this. Can you try both variants and see if there's any change? Can you try running randomio and "diskinfo -vt" on the gmirror volume? Diskinfo should give one interesting result - with a proper patch and with two drives it should reduce full stroke to sequential. --------------enigD8A6AFEB1FFA72A04307253B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkn3SzAACgkQldnAQVacBch8FACg65hnKe02MMFnHZ8a6t/Kb/de J/8An27xQQbbCRI7283Xp0M8nDwVDD/S =NIT0 -----END PGP SIGNATURE----- --------------enigD8A6AFEB1FFA72A04307253B--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?gt7i03$eov$1>