Date: Sat, 14 May 2005 13:01:43 -0400 From: Paul Mather <paul@gromit.dlib.vt.edu> To: Dominic Marks <dom@goodforbusiness.co.uk> Cc: pjd@freebsd.org Subject: Re: gmirror Message-ID: <1116090103.3699.43.camel@zappa.Chelsea-Ct.Org> In-Reply-To: <200505141130.01541.dom@goodforbusiness.co.uk> References: <20050514093217.C6088E082A@oak.tantieme.ru> <200505141130.01541.dom@goodforbusiness.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 2005-05-14 at 11:30 +0100, Dominic Marks wrote:
> The seek times are way down, which is great, and makes sense using a
> round-robin strategy on the mirror, but my peak transfer rate has been
> almost halved too.
>
> I don't mind this too much as in my application low seek times are worth
> more than high transfer rates, but it is still puzzling to me to see such a
> remarkable drop in throughput.
For large sequential reads on a round-robin mirror, you might be forcing
each drive to do a lot more small seeks than if you just accessed the
data from a single drive, and those small seeks may be slowing down the
overall transfer significantly. I would have thought that large,
whole-track caches prevalent on modern hard disks would ameliorate that
problem in an otherwise quiescent environment, but, dependent upon the
drive's caching policy, you never know...
Cheers,
Paul.
--
e-mail: paul@gromit.dlib.vt.edu
"Without music to decorate it, time is just a bunch of boring production
deadlines or dates by which bills must be paid."
--- Frank Vincent Zappa
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1116090103.3699.43.camel>