Date: Sat, 21 Aug 2004 10:06:14 +0200 From: Pawel Jakub Dawidek <pjd@FreeBSD.org> To: "Kenneth D. Merry" <ken@kdm.org> Cc: freebsd-performance@FreeBSD.org Subject: Re: RAID-3? (was: cvs commit: src MAINTAINERS) Message-ID: <20040821080614.GC30151@darkness.comp.waw.pl> In-Reply-To: <20040820223446.GA18838@panzer.kdm.org> References: <41449.1092750244@critter.freebsd.dk> <200408161043.i7GAhfXs079045@repoman.freebsd.org> <20040817004407.GA81257@wantadilla.lemis.com> <20040817074633.GO30151@darkness.comp.waw.pl> <20040817112900.GA31635@freebie.xs4all.nl> <20040817124020.GK88156@wantadilla.lemis.com> <20040817131612.GT30151@darkness.comp.waw.pl> <20040819024359.GA85432@wantadilla.lemis.com> <20040820193547.GZ30151@darkness.comp.waw.pl> <20040820223446.GA18838@panzer.kdm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--f9lFb+Z4UT82L8vr Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 20, 2004 at 04:34:47PM -0600, Kenneth D. Merry wrote: +> > PS. I wonder about read optimization, so parity component can be also +> > used for reading in round-robin fashion... +>=20 +> That likely wouldn't speed things up too much. The hard drives are doing +> read ahead anyway, so they'll usually have the data ready when you go do= wn +> to read the next block if you're doing sequential reads. +>=20 +> You would also spend more CPU power to reconstruct the piece of data you +> didn't read from the disk. That'll probably increase your latency +> somewhat, and you would also be touching all of the data with the CPU. +>=20 +> As PHK said, it might be more interesting to do data integrity checking = on +> reads. The problem, of course, is that you wouldn't be able to correct +> problems, you would only be able to detect them. Those are results from RAID3 test without one data component, so parity has to be calculated. RAID3 in degraded mode: Number of Bytes per Requests per Operations processes second second ---------------------------------------------------------------------- READ 3 6329500 95 READ 15 9104075 136 READ 100 10895041 163 WRITE 3 5112288 76 WRITE 15 7911875 119 WRITE 100 9104075 136 READ/WRITE 3 6097224 91 READ/WRITE 15 8307468 125 READ/WRITE 100 9773492 147 Here are already presented results of full RAID3: RAID3: Number of Bytes per Requests per Operations processes second second ---------------------------------------------------------------------- READ 3 6329500 95 READ 15 8981047 135 READ 100 10719314 161 WRITE 3 5073263 76 WRITE 15 7467387 112 WRITE 100 8631136 129 READ/WRITE 3 6041795 90 READ/WRITE 15 8104847 121 READ/WRITE 100 9494250 142 So as you can see there are no difference in reading (actually reading in degraded mode is even a bit faster, hard to say why). Thread, which was responsible for XOR calculations was consuming 6-7% of CPU on 534MHz Celeron. PS. I removed cvs-*@ from CC. Let's continue on performance@. --=20 Pawel Jakub Dawidek http://www.FreeBSD.org pjd@FreeBSD.org http://garage.freebsd.pl FreeBSD committer Am I Evil? Yes, I Am! --f9lFb+Z4UT82L8vr Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBJwJ2ForvXbEpPzQRAnhcAJ9ZpCcFwICzp5WELvGhRK/63uMuBQCdEkRy NXosbN6Lcr6Wh7Iy4MvPkho= =nh6l -----END PGP SIGNATURE----- --f9lFb+Z4UT82L8vr--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040821080614.GC30151>