Date: Thu, 19 Aug 2004 17:07:32 +0930 From: Greg 'groggy' Lehey <grog@FreeBSD.org> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: Wilko Bulte <wb@freebie.xs4all.nl> Subject: Re: RAID-3? Message-ID: <20040819073732.GV85432@wantadilla.lemis.com> In-Reply-To: <12437.1092899768@critter.freebsd.dk> References: <20040819070716.GS85432@wantadilla.lemis.com> <12437.1092899768@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
--thwsKKN5whlRGe6j Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thursday, 19 August 2004 at 9:16:08 +0200, Poul-Henning Kamp wrote: > In message <20040819070716.GS85432@wantadilla.lemis.com>, "Greg 'groggy' Lehey" > writes: > >>> Every write takes exactly the same amount of time. >> >> Which, including aggregate seek time, is longer than for RAID-5, >> because more disks are involved. > > RAID3 is within epsilon of the single disk because all the disks > work in unison. Exactly the point I'm trying to make. For multiple transfers, all other RAID forms are faster than a single disk. > (Spindle-sync is a good idea btw). It can't harm. But how much difference does it make with modern cached drive? >>> There is no waiting for data to be read off of any disks. >> >> Sure there is. There's always waiting for data to be read off disks. >> That's part of the way disks are built. You've got to seek first, >> then you've got to get the head over the data. That's why I said that >> RAID-3 is only useful for sequential transfers. > > You're wrong. RAID-3 is good for normal usage. The point is that > you don't have to do the complicated "I have disk1 in my cache but > that is not the parity and not the one I'm writing so I need to > read 2,3 and the parity which is 4 and then write my data to disk > 5 and calculate and update the parity on 4" dance. Agreed. Easier on the programmer. The user pays. > RAID3 works by: > > A write-request: > ... > > A read-request: > ... Yes, I know all this, once we've accepted that we are no longer dealing with the real RAID-3, but a modified version. It has in common with the original RAID-3 that while we're doing this, the other requests are waiting for us to get our act together. > read parity from disk5 and check Really check every time? I would have thought you'd only use the parity disk if one of the other ones had gone down. > And that is _all_ there is to it. "What you see is all you get". >> Note, of course, that RAID-5 is relatively good on reading. The big >> disadvantage of RAID-5 is when you write. > > RAID3 doesn't suffer and is very predictable in either mode. As I pointed out earlier, predictability and performance are two different kettles of fish. >> Of course it has. Once you spread your data out over more than one >> disk, you need some kind of mapping. What we're talking about here >> appears to be an implicit one sector stripe size, though the original >> paper talked of a stripe size of one byte. > > Forget the original paper. Why? > Original papers are full of things people have not found out yet. I'm not sure how to interpret this. Greg -- Note: I discard all HTML mail unseen. Finger grog@FreeBSD.org for PGP public key. See complete headers for address and phone numbers. --thwsKKN5whlRGe6j Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (FreeBSD) iD8DBQFBJFi8IubykFB6QiMRAno0AJ9pxI/c5bluqijVcfngSrC9hcKV4QCfSZEj 78rxXP8+08bIe7r+VBX6Prc= =GzMZ -----END PGP SIGNATURE----- --thwsKKN5whlRGe6j--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040819073732.GV85432>