Date: Tue, 8 May 2001 09:38:37 +0930 From: Greg Lehey <grog@lemis.com> To: Linh Pham <lplist@closedsrc.org> Cc: Bob Greene <rgreene@tclme.org>, "Andrew C. Hornback" <hornback@wireco.net>, Steve Blanzy <sblanzy@aperion.com>, FreeBSD Questions <questions@FreeBSD.ORG> Subject: Re: Raid Message-ID: <20010508093837.A66817@wantadilla.lemis.com> In-Reply-To: <Pine.BSF.4.33.0105070917330.97088-100000@q.closedsrc.org>; from lplist@closedsrc.org on Mon, May 07, 2001 at 09:21:33AM -0700 References: <3AF6CCDB.F1029665@tclme.org> <Pine.BSF.4.33.0105070917330.97088-100000@q.closedsrc.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Monday, 7 May 2001 at 9:21:33 -0700, Linh Pham wrote: > On 2001-05-07, Bob Greene scribbled: > >> Well, you wrote the book; I've only read it. Is this a vinum specific >> performance penalty? I suppose you're talking about the requirement to read before writing. No, that's not a Vinum-specific problem. All RAID-5 systems must do that. > I think the performance penalty affects almost every RAID 5 array, > since you have to update the ECC data on all of the remaining drives > so that the entire file system is still accessible. I didn't mention this "penalty", because it's insignificant. One of the reasons that Vinum performs better than many "hardware" arrays is because the processor on a PC is much faster. Even on the 486/66 on which I originally developed Vinum, the parity calculations were of hardly any relevance. > If I remember correctly... you can still have all your data as long > as no more than one drive were to fail in a single array at any > given time. To unmangle that... if you lost one drive already and > another one fails... I think your screwed. Correct. I mentioned that in my earlier message. There are significant performance penalties for recovering data from a degraded array. Write performance, on the other hand, is better when the array is degraded. Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010508093837.A66817>