Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 12 Dec 2009 18:59:11 -0700
From:      Will Andrews <will@firepipe.net>
To:        Maxim Sobolev <sobomax@FreeBSD.org>
Cc:        svn-src-stable@FreeBSD.org, Alexander Motin <mav@FreeBSD.org>, src-committers@FreeBSD.org, svn-src-stable-8@FreeBSD.org, svn-src-all@FreeBSD.org
Subject:   Re: svn: stable/8/sbin/geom/class/mirror
Message-ID:  <20091213015909.GB27552@cephei.firepipe.net>
In-Reply-To: <4B21A4B9.3070005@FreeBSD.org>
References:  <200912102351.nBANpOKc078607@svn.freebsd.org> <4B21A4B9.3070005@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help

--/04w6evG8XlLl3ft
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Dec 10, 2009 at 05:47:37PM -0800, Maxim Sobolev wrote:
> Alexander Motin wrote:
> > Author: mav
> > Date: Thu Dec 10 23:51:24 2009
> > New Revision: 200373
> > URL: http://svn.freebsd.org/changeset/base/200373
> >=20
> > Log:
> >   MFC r200282, r200290:
> >   Change gmirror default balance algorithm from "split" to improved "lo=
ad".
> >   "split" is very ineffective for devices with rotating media as HDDs.
> >   To be effective, it needs that transfer time reduction due to block
> >   splitting was bigger then access time increase due to non-sequential
> >   access. For modern HDDs I was able to reproduce it only with read siz=
es
> >   of 2MB and above, which is almost not applicable in real life.
> >   "load" algorithm same time is more universal and effective now.
>=20
> The other problem with real hard drives is that they usually read much=20
> more data than requested. Some suggest that they read as much as one=20
> track each time the data is not in cache even if one sector has been=20
> requested, therefore splitting request of any reasonable size is=20
> meaningless, as it would simply cause both drives to load essentially=20
> the same data, wasting half of available I/O bandwidth and in addition=20
> you cause both heads to do seek, which makes it even worse.

Indeed.  I think the benchmarks speak for themselves.  The new algorithm
results in much lower average I/O service time, due to the seek time
reduction by dispatching read requests to providers according to the known
distance from the request, and also reduced by taking advantage of the disk
cache.  The disk cache size probably affects how close the requests need to
be for optimal selection, so perhaps a sysctl is warranted to allow
administrative adjustment of this value from mav@'s default of 1MB.

Regards,
--=20
wca

--/04w6evG8XlLl3ft
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.13 (FreeBSD)

iD8DBQFLJEpsF47idPgWcsURAr+TAJ9w2xTaZbGnaaHgxyU+skbbgO9tJwCeKpQr
ezdqYqoywQehKVEpCwuJa2w=
=LdnI
-----END PGP SIGNATURE-----

--/04w6evG8XlLl3ft--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20091213015909.GB27552>