Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 18 Dec 1998 07:42:48 -0500
From:      "Gary Palmer" <gpalmer@FreeBSD.ORG>
To:        Dan Swartzendruber <dswartz@druber.com>
Cc:        Greg Lehey <grog@lemis.com>, Matthew Patton <patton@sysnet.net>, freebsd-isp@FreeBSD.ORG
Subject:   Re: RAID solutions? 
Message-ID:  <68920.913984968@gjp.erols.com>
In-Reply-To: Your message of "Thu, 17 Dec 1998 22:15:28 EST." <3.0.5.32.19981217221528.009cb980@mail.kersur.net> 

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?68920.913984968>