Date: Wed, 06 May 2009 20:21:39 +0100 From: Matthew Seaman <m.seaman@infracaninophile.co.uk> To: Gary Gatten <Ggatten@waddell.com> Cc: freebsd-performance@freebsd.org, freebsd-questions@freebsd.org Subject: Re: filesystem: 12h to delete 32GB of data Message-ID: <4A01E343.4020608@infracaninophile.co.uk> In-Reply-To: <70C0964126D66F458E688618E1CD008A0793EBD4@WADPEXV0.waddell.com> References: <70C0964126D66F458E688618E1CD008A0793EBD4@WADPEXV0.waddell.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigD7935878E099234D25665A93
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Gary Gatten wrote:
> OT now, but in high i/o envs with high concurrency needs, RAID5 is
> still the way to go, esp if 90% of i/o is reads. Of course it depends
> on file size / type as well... Anyway, let's sum it up with "a
> storage subsystem is only as fast as its slowest link"
It's not just the balance of reads over writes. It's the size and sequen=
tial
location of the IO requests. RAID5 is good for sequential reads -- eg.
streaming a video -- where the system can read whole blocks from all the
drives involved, calculate parity over the whole lot and then push all th=
at
blob of data up to the CPU.
RAID5 is pretty pessimal if your usage pattern is small reads or writes
randomly scattered over your storage area -- eg. typical RDBMS behaviour
-- which works a great deal better on RAID10.
I'd also contend that the essential difference between a really good fast=
hardware raid controller and something disappointingly mundane is a decen=
t
amount of non-volatile cache memory. For most H/W raid that equates to
using a battery backup unit. I've been thinking though that a few GB of
fast solid-state hard drive configured as a gjournal for a RAID10 (ie gst=
ripe
+gmirror) might achieve the same effect for rather less outlay... It
would probably not be too shabby with RAID5 even, but of course you'ld
lose the benefit of offloading parity calculations onto the RAID controll=
er's
CPU. Still, modern multi-core CPUs are probably fast enough nowadays to
make that viable for many purposes. =20
Cheers,
Matthew
--=20
Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard
Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
Kent, CT11 9PW
--------------enigD7935878E099234D25665A93
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEAREIAAYFAkoB40kACgkQ8Mjk52CukIxlQwCfZUK2JDHgQBeZ+hAkCZImW2pO
SkEAoIyWUGFD7u0sDmqjueBr6w6TokAG
=zm6f
-----END PGP SIGNATURE-----
--------------enigD7935878E099234D25665A93--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4A01E343.4020608>