From owner-freebsd-isp Fri Dec 18 04:43:22 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA04159 for freebsd-isp-outgoing; Fri, 18 Dec 1998 04:43:22 -0800 (PST) (envelope-from owner-freebsd-isp@FreeBSD.ORG) Received: from gjp.erols.com (alex-va-n008c079.moon.jic.com [206.156.18.89]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA04152 for ; Fri, 18 Dec 1998 04:43:20 -0800 (PST) (envelope-from gjp@gjp.erols.com) Received: from gjp.erols.com (localhost.erols.com [127.0.0.1]) by gjp.erols.com (8.9.1/8.8.7) with ESMTP id HAA68924; Fri, 18 Dec 1998 07:42:49 -0500 (EST) (envelope-from gjp@gjp.erols.com) X-Mailer: exmh version 2.0.1 12/23/97 To: Dan Swartzendruber cc: Greg Lehey , Matthew Patton , freebsd-isp@FreeBSD.ORG From: "Gary Palmer" Subject: Re: RAID solutions? In-reply-to: Your message of "Thu, 17 Dec 1998 22:15:28 EST." <3.0.5.32.19981217221528.009cb980@mail.kersur.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 18 Dec 1998 07:42:48 -0500 Message-ID: <68920.913984968@gjp.erols.com> Sender: owner-freebsd-isp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Dan Swartzendruber wrote in message ID <3.0.5.32.19981217221528.009cb980@mail.kersur.net>: > Mirroring sucks for this, no? Twice the space, and you still have to do an > extra write, don't you? I know it can be faster when reading (I work at a > company that does fault-tolerant TP systems, so we have to deal with these > issues...) I'm no expert on this, but my understanding is as follows (for normal mode ... degraded mode is something else entirely) For systems with sequential writes, random reads (e.g. CNFS): RAID5 is not a bad choice. The parity block is normally in cache, so there is only on extra write. The read operation incurs 0 overhead. There is no penalty on an unclean shutdown. Operation under degraded mode depends if you have a hot spare immediately available for the parity rebuild or you have to replace the disk first. The parity rebuild is normally expensive. RAID 0+1 (or 1+0) (depending *very* much on how the mirror is written), then you can see a performance gain, as the reads can be interleaved between the two plexes in the mirror set. Performance will very much depend on if you are a read-mostly (e.g. news) or write-mostly (e.g. logs) scenario, and how effecient your software is. Recovery can be a pain. Veritas Volume Manager, if you don't have something called a DRL (Dirty Region Log) will re-sync the entire plex after an unclean shutdown. (Of course, hardware solutions don't suffer from the rebuild penalty, in theory, thanks to the battery backed cache). On systems at work this takes over an hour (even for relatively ``small'' plexes of 18gigs), and during this time disk performance is really degraded. For systems with random reads, random writes (e.g. Oracle) RAID5 is a BAD BAD choice. There is a very good chance that the parity block that needs to be updated is not in cache, so it incurs a read and a write (minimum). This tends to thrash the cache (especially on hardware controllers, even if they're designed for RAID5), and can degrade performance even more than you'd think at first. On the other hand, RAID 0+1 is a relatively safe choice for this application. With the addition of a DRL (or some similar feature, for software RAID anyhow), recovery time is small (a few minutes at most). If the software is intelligent, it can also optimize disk I/O by interleaving reads and writes to the plexes, so your read can go to one plex, while a write is happening to another plex in the mirror. Now the usual caveats: I've not had a chance to look at Vinum, so the only experience I have is CCD (last looked at over a year ago), VxVM and the high-end Symbios (now LSI) SCSI2SCSI RAID controllers (both under Solaris). Gary -- Gary Palmer FreeBSD Core Team Member FreeBSD: Turning PC's into workstations. See http://www.FreeBSD.ORG/ for info To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isp" in the body of the message