How to use MacOS X's Built-in Software RAID?

You should be able to simply install another disk of the same capacity (preferably not on the same IDE controller), boot up, and add the disk to your boot disk to form a RAID 1 mirror set as per the post above.

However, software RAID adds overhead, and I think it may disappoint you w.r.t speed. In general, hardware-based RAID is preferable. I suggest that you get a an Acard ATA133 IDE RAID card, two ATA133 drives, and mirror or stripe those. If you really want to get serious, get an external RAID 5 SCSI array.
 
I don't mean to sound antagonistic, but I disagree completely w.r.t. speed of software RAID when using RAID 0 or 1. There is so little thinking that needs to occur that it's trivial to do the normal work in software.

As for simply mirroring a drive that already exists ... don't do that. Consider making a RAID array the same thing as formatting. (which it pretty much is) You can't format a disk and retain data. Just like you can't make a RAID set while retaining data. You'll have to move your data off of your drive to configure RAID on that drive. I don't think Apple's utility supports, or should support magical mirroring and RAIDifying a single drive onto another.

You could install the drive and just copy your data over. RAID -1 :) I recommend that you never run you Hard Drive (main one anyway) at more than half full. If it's more than half full, you need a bigger drive. this keeps you from having to really care about disk and file fragmentation / optimization.
 
Actually the point of RAID has nothing to do with speeding up the system. RAID, as the acronym stands for "Redundant Array of Independant Disks" (some also mention it being Inexpensive not Independent, but doesn't really matter). Now lets go over the different types of RAID, and what you gain by it, and what you lose. (I'll be skipping the hybrid/vendor-made-up RAID levels as it only gets more confusing )

RAID 0: This is just striping of data across disks. To be honest, this is not truely RAID, as no redundancy is added, but some reason this got the tag of RAID. What you do gain from RAID 0 is an increase in read and write speed due to the data going across different wires and being written to different platters. So instead of writing 100k on one platter on one disk, that 100k can be spread across 4 platters in 25k blocks. This allows you to do more reads and writes simultaneously.

RAID 1: This is mirroring of data. One disk is the exact copy of the other. You get both performance hits, and performance gains with this. The performance hit is you need to do a write twice the write (altho your write call returns after the first, the second is handled by the RAID software). The performance gain is being able to have two disks in which you can read the same data from.

RAID 2: It exists, but not even worth mentioning, it's purely academic

RAID 3:
RAID 4: These are basically the same, they create redundancy by creating a parity disk which is used to recreate the data of any disk that fails. Their differences have to do with the way the data is written to the non-parity disks, but not really relevant here. Both get very high read rates, but RAID 3 historically has very good write rates also, and RAID 4 has bad write rates, but depending on the implementation this may or may not be true (some hardware vendors have very fast RAID4)

RAID 5: This is probably the most common RAID, as it gets the best performance in relation to the cost. RAID 5 spreads the parity blocks across disks. In the event of a failure of any disk you have a X-1 in X chance of not having to recreate parity on a block (where X is the total number of disks in the RAID). You get an increase in read performance with RAID 5 and ok write performance.

Ofcourse, on all these it's assuming it's software RAID. The only one of these whose write rate will be faster then a single disk will be RAID 0, all the others will have a bottleneck of writes based on the sleep of the slowest disk. In hardware based RAID it's an entirely different ballgame, and you can take most of what you know about RAID performance and toss it out the window depending on the vendor.

As to the software RAID in OS X, it's not very useful for most folks. You do not have the ability to use RAID on your boot disk (unless you have an X Serve). So, if you wanted to mirror your drives you'd have to put in two additional drives for your data. As someone mentioned there is a card out ther now that claims they do RAID 1 and can boot OS X with it, but I've yet to see it, and can't see spending $150 to find out (it's done RAID 0 for awhile, but I could care less about RAID 0).

If you really want to learn more about RAID there is a decent tutorial at: http://www.ecs.umass.edu/ece/koren/architecture/Raid/raidhome.html

Brian
 
I hate it when people say that software RAID is worthless. It's a software implementation, like VPC is a software implementation of a PC. Sometimes it's exactly what you need, and free is a whole lot cheaper than $150.

I have 2 30G 5400 RPM drives combined in a stripe set. The throughput is roughly double what the individual drives are. The capacity is double what each drive is. Convenient for pushing around 20-40 G at a time.

As for compatibility with my OS, I'll take OS level software RAID over motherboard RAID any day.

And on the topic of performance, Hardware kicks everybody's butt. But SCSI has virtually nothing to do with performance, or RAID. No drives outrun their busses, so the bus speed is not a big factor.

Anyway, this thread was about trying RAID with OS X. There's another thread here about What is RAID. And in line with the usefulness that btoneill mentioned, 9 Classic doesn't run from a striped array, probably not from any software RAID set. Just in case you were planning on that. :)
 
I have slow, fat, cheap drives. Their theoretical sustained maximum is about 15MB/sec and in practice copying from (or to) one of these drives I tend to get a real solid 10MB/sec.

Using them mirrored, I found no difference in performance from a single drive, except that waking from drive sleep took twice as long.

Using them striped, I find that I get a pretty consistent 18-20MB / sec. This is throughput with files all larger than 4MB, many larger than 100MB. My processors aren't being used much. <20% each anyway. So my throughput doubles, which goes along with theory. Latency may actually get worse, but if I wanted reduced latency, I'd get better drives. That, and X does a real nice job of drive caching, so it solves a lot of latency issues itself; again, in software.

I am on a dual 450 G4, so my processors are good but not phenomenal, and the drives are inexpensive, so Mac OS X's software RAID is worth enough to me that I use it, and even want software RAID 5 to be an option. In an XServe it may be of questionable value, but in a home machine, it's a really sweet option that adds near 0 cost to manufacturing. Yay - value added to my already existing hardware.

As for the article, I think it's a fairly poor and plebeian explanation of RAID striping as though that was all RAID could do. The speed test done was a finder Duplicate on the array ... this is an awful test of performance except for finder duplicating. The request to read and write data from the same drive at the same time is THE wrong way to test typical throughput of a low-load RAID array. No wonder they got "up to 25% faster" ... painful.
 
I got the RAID for my Mac out of curiosity really - I have a ATTO SCSI 160 card with 35Gb Seagate drives, using the Drive Setup utility I made these into my Work volume.

I am a Photoshop user so IO performance is my main bottleneck - I have to say I was not blown away by the performance of this setup - it is faster but not by a big margin.

Hats off to Apple for making things so easy though...

I moved over to OSX 3/4 months ago - and love it - I can do almost everything with it and it almost never crashes.

Off topic can anyone explain why the network performance is so fast when my OS 9.2 workmates copy work from me over the network ?


:)
 
I tried to use Disk Utility in OS X to use software RAID with two 4GB SCSI hard drives, one is made by Quatum while the other one is by IBM. It worked. However, OS X Installer CD does not recognize the RAID hard drive.

Anybody wants to guess what might have happened?

Hardware (Apple Computer Parts):

Beige G3/233 Baby Tower

4GB IBM SCSI hard drive
Model # DCAS-34330

4GB Quatum SCSI hard drive
Quantum Fireball ST

Regards,
George Lien
 
Well, OS X can't boot onto a raided harddrive, so it makes sense the installer can't find it, or maybe it does find it, and just doesn't show it, as kinda useless to install the os on a disk that you can't boot off of.

Brian
 
Hmm...

Software RAID in Linux and Windows 2000 are so easy.

<Sighs> I was hoping to use it to see a performance change.

Guess that's not happening.
 
these are THE terms to know if you're going to discuss RAID. RAID can improve throughput, availability, or both. In software you only expect improvement on one or the other. To improve both, you really need dedicated hardware.

RAID does not improve latency. caching improves latency. Faster drives have improved latency. So if what you are doing requires many small fast unassociated reads, like booting an OS, VW swap, or photoshop scratch space, then RAID won't help you. At least not much.

Other uses, like massive file transfers (HD images) or data protection, are good ways to use RAID. Understand, appreciate, implement, criticize. Doing these things in any other order would be uncivilized.
 
Originally posted by pianophile
However, software RAID adds overhead, and I think it may disappoint you w.r.t speed.
Click to expand...

Actually, the way Apple implements RAID, even a mirror is faster than a single drive... at least on the Xserve (just not sure about on other systems).

On the Xserve, when a mirrored RAID writes at essentially the same speed as a single drive. But when it reads, it has two drives to read from. So it very intelligrntly reads from both. It doesn't read twice as fast, but it is faster than reading from a single drive. While one drive is reading, the other is seeking for the next chunk. The technology is called "ping-ponging."
 
OK, I have a pair of 30s in striped mode right now, but I planned on grabbing a couple of 120's and mirroring them so that I could care less about frequent backups. I was delaying due to price and performance, but knowing this, I think I'll hop on that mirroring bandwagon. That friggin' rocks! I totally wasn't expecting any performance improvement from reading on a mirror set.

Dude, that rocks. Macs Rock! Dude, you rock!
 
***********WARNING*********************

RAID1 mirrors disk blocks - it's goal in life is to make sure each disk involved in a single write operation contains the same data. The redundant levels of RAID are not a substitute for backups. Corrupt your data and/or filesystem & RAID1 will perfectly mirror garbage!!

***********WARNING*********************


OK, had to put the important warning out; now the details.

I am very new to this OS, but have been designing RAID systems for UNIX since 1989. I currently am a contract instructor for Veritas RAID, filesystem, and backup products.

If we are using RAID, and doing writes, what happens if the system crashes before the all writes to the multiple disks that comprise your filesystem complete? CORRUPTION of data can happen, so U gotta do backups too.

Take the following info with a grain of salt. Commercial UNIX's have 64 bit UID's so they need to support a few more concurrent user's than the typical Mac system does. RAID10 requires at least 4 disks. RAID5 requires at least 3 disks. RAID1 (mirroring) requires at least 2 disks. RAID1 by intself will be just fine for many of us cuz we don't NORMALLY write lot's of files larger than 64KB at the same time. RAID1 can have better read performance; it uses a round-robin technique to alternate read operations between disks. Write performance is about the same unless we are in a heavily loaded & write-intensive environment. Heavily loaded is when disk utilization as measured by #iostat is> 25-30%. Write intensive is when total I/O operations divided by total writes is greater that 25%, or 15% if using NFS version 2.

A 10,000 RPM 18GB SCSI disk can do about 120 I/O operations per second. At 64 KB per I/O, this comes close enough to 8MB per second I/O bandwidth per disk. Newer larger disks can write more than 64KB per I/O & will have higher bandwidth IF your app sends larger chunks. Otherwise, your are throttled rotational latency (RPM) & seek time. You might think that with a larger capacity disk, the sectors are closer together so rotational latency SHOULD improve. This not entirely true - sector 8 is not physically next to sector 9, it is about 4-5 sectors away. This gives the disk drive H/W time to digest sector 8 while rotating to sector 9. Go to http://docs.sun.com & look at the #tunefs command to see how you too can second-guess the disk drive engineers. We will not get this level of performance going thru the filesystem. You can use the #time command & compare copying data with #dd versus #cp on the same size chunk & see the difference between raw disk performance (8MB per second) and filesystem perormance moving the same amount of data. This is why the big dogs run Oracle on raw partitions. If you wanna do muplitle runs of #cp, you gotta #umount them #mount the filesystem to flush all the file blocks cached in memory.
If your application requires more disk bandwidth, you gotta stripe.

The best RAID: Mirror in hardware, stripe in S/W. This is RAID 1+0, AKA RAID10. Runner-up is to do both 1+0 in S/W. RAID10 tolerates multiple disk failures the best. I had a student from Intel that was combining over 100 disks (yes, they use UNIX when they need to do REAL work).

The worst RAID: RAID5 in S/W, runner-up RAID5 in H/W. Only tolerates single disk failure. People make fun of you. Recovering the RAID5 volume after replacing a failed disk (read data, X-OR it then re-write) can take hours. If you do less than a full-stripe-write, you must first read the entire stripe to properly X-OR the new & existing data, this is done at the sector (512 bytes) level. This operation is called READ-MODIFY-WRITE for those of you wanting more gory details. Virtually all my customers on RAID5 were unhappy with performance.

I am about 99% sure that Apple's Xsrever RAID box will do RAID10. With H/W RAID changing a failed disk & resyncing the RAID (re-mirroring the data in the case of RAID1) is easier. Hot sparing is better in H/W RAID as well. If you must have the biggest & smartest dog, you can get some EMC & have up to 64GB front-end cache on your H/W RAID box. With the leftover change you could get a SAN, Veritas Netbackup with the "server-free-backup" extension, & do your backups directly from device-to-device. The code even runs on the switch.

When stripng, never use a stripe size smaller than 64KB unless you can prove via benchmark that a smaller size is better. When striping, it is useful to know the characteristics of the reads/writes your application(s) issue. AKA are we doing random of sequential I/O? If you are doing sequential I/O, your "full-stripe-width" (stripe-unit-size*number of disks) should equal the size of writes your application issues. If your app isuues 256KB I/O's, use 4 disks with a STU of 64KB.
On SunOS, I would say

#iostat -x, then for each disk look at the amount of data written, divide by the number of write operations to get a fair idea of my iosize. Unless otherwise stated, volume of data is expressed in sectors; 512 bytes.

Since the man page & the iostat command don't on this OS, I dunno - man says use #iostat -D.

If you are random I/O, use STU of 64K, and as for number of disks, more is usually better. Just remember that on SCSI for example, more than 4 heavily utilized disks will saturate a single SCSI bus. On old versions of Veritas Volume Manager, we used to say max disks = 8, Veritas Volume Manager wouldn't scale well beyond 8. I do not know where MACOSX hits the wall on # of striped disks. On Veritas, the S/W RAID stuff uses kernel memory, so U gotta be careful.

When I explain random I/O to my students, I use the grocery store example; the more checkout lines that are open, the less chance we have of getting in the line where the guy has an outta town check. With random I/O, the less chance we wanna use the same disk some other process is already in line for.

I will write more later as I figure this stuff-out
 
OK, well since we've decided to unearth this horse and bit him around a little, here's what I know.

Apple's X-Serve does hella RAID5, and what level it does reads and writes at is immaterial to me as it does it all in hardware before my server ever sees it. Also, the uptime on the box is really sweet. While it did indeed take close to 24 hours to format a RAID5 set, it was available almost immediately. The hardware will do the work while still reading and writing. Same goes for a drive replacement. Pop out a drive, a little warning light comes on, data still flows. Pop in a new drive, data gets mirrored / regenerated, data continues to flow. Sun's beasts add controller failover, higher performance, and one helluva price tag to the mix if you need something more industrial.

As for performance and matching write sizes to logical write stripes ... shouldn't a good caching mechanism on a hardware based array pretty much abstract that out? I mean issue 4 64's and you fill a 256. If the drives are just coming into position by the time the 4 64's are sent then it all goes at once anyway. And sending a 256 when the drive has to write 4 64's ... again, so what? Provided your cache remains consistent and could weather a power outage (battery backup on the X-serve, or just a really good UPS) And the issue of a mirrored array becoming inconsistent in a system crash ... that's abstracted away with journaling I believe, even on a mirror set. Either the data made it or it didn't, and you might lose the data that was sent right when the system crashed ... but, duh.

Speed on the X-serve's hardware RAID5 is ... (well I'm going to blame HFS+ and Mac OS X and Finder for the horrible performance on small files, but) I can read or write around 75MB per second on each of the 6 disk RAID sets, with multiple gigabyte files. If I striped the sets together that'd give me 150MB/s along with the ability to remain available at full speed in the event of a single drive failure. And short of a physical assault, how often do multiple drives fail simultaneously in a controlled environment? My logic for blaming the OS for the performance on smaller files is that the processor on my server hits 100% (while the other processor on the server is idle) and the blinky lights on the RAID box indicate minimal load.

Although mirroring and striping are available in hardware in the X-Serve, the left half and right half are completely independent units. The only way to stripe across the two of them is in software on the server. This scales just like the numbers show it should, at least on other drives I've used, I really didn't play too much with the X-Raid before we had mission critical data on it. I'll agree that writes are disproportionately slow compared to reads on RAID5, but when properly handled this isn't a problem, as the bottleneck of drive performance is spread evenly across all of the drives. A 5 disk RAID 5 set should have twice the write performance of a single drive on small writes, and 4 times the performance of a single drive on large writes. This is in line with what I've seen on the X-Serve.

(rant)With the exception that the Finder in 10.2.6 Server handles large copies of many small files as intelligently as a seamonkey on ritalin. I ran out of RAM (and scratch space) doing a massive file copy, and the Finder bombed. Admittiedly it was several million files and about 200GB of data, but I had like 50G free on the scratch drive and 2GB of RAM. It was a friggin copy! So then I repeated the task in smaller chunks and began reviewing my command line options for moving data while preserving resource forks. Anyway ... (/rant)

And since you mentioned netBackup ... oi vey. That puppy is inconsistent, and unreliable for us. Admittedly we're probably pushing it to its limits, but it just doesn't handle heavy load very well. And then if someone backs up during a catalog rebuild it all goes to hell, and we have had to rebuild the server. Not trivial since those take several hours nightly for us. It's pricey too. The file recovery and security have been great, if netbackup has actually been backing up. However, the server and client often disagree about the state of the backup. The client doesn't complain properly if it hasn't backed up. The server may think everything is fine. We have 3 servers, and each one has it's own quirks. They are supposed to be identical. And we can't patch the OS because it breaks NetBackup... If you're going to talk backup to me, talk Retrospect. It's feature list isn't as cool as netbackup, but it has never lied to me, and I have a current 98%+ successful backup rate on that; veritas has (checking...) approx 85% fully functional clients. And we keep working on those. Retrospect I just let sit. And if I add too many clients for it to back up in the time interval I specify, it just takes a little longer to cycle through and back everyone up. It's the most graceful possible failure mode for an overloaded backup server.

If you want to talk about interesting RAID stuff and reliability, you'll want to talk about Network Appliances, which fits in with your mention of a SAN. All the file recovery coolness of NetBackup, tons of throughput, reboots times of well under a minute, multiple terabyte volumes, expandable upon the addition of new drive sets, all hardware all automatic rebuilds. Supa sweet. Also pricey though.

The really cool thing about software RAID5 is cost. Seriously. If you don't need more than a couple of MB/sec throughput, and you have a p200 around, three matched ata drives and another to boot from, linux, and day or two to configure. Put it on your SAN, and you have a sweet personal backup and storage box (or mp3 server) that will tolerate a disk failure, for the price of a couple of common drives and hardware that would otherwise be scrapped. Say 3 120GB drives for a total of $400, maybe $200 for the rest of the rig and a network card. I'd LOVE to have software RAID5 on Mac OS X. I've been tempted on numerous occasions to try my hand at kext hacking and port the BSD stuff over. Cost effective drive failure tolerance is just a cool idea. If you're on windows it doesn't matter because something will logically hose your data before your hardware fails. (at least from what I've seen doing tech support) On other OSes though, it's cool.

Whew! OK, I hereby declare that each of us needs to get a life, and become way more succinct in our posts. Just under a year since my last post in this thread. I'm not sure what that means. Maybe November is RAID month?
 
theed, you rock dude!!

If you are writing to something with cache, yup it doesn't matter til the cache fills-up & starts madly writing files (usually the oldest) to disk. Last time I used EMC, default was to set the high water mark at 85%.

Two problems, (1) management likes to save money, consolidate so a big box of disks may host multiple hosts/apps.
Read intensive apps would like the cache to stay as full as possible, write intensive just the opposite. Mix these together on the same box of disks & bummer. (2) Really write-intensive apps will fill the cache up, so you end-up writng all the time anyway, & the cache just becomes an extra step involved in getting our data to disk, AKA bottleneck.

As for the need of backups with mirroring/journaling I'll have to go out on a limb & assume that HFS+ journaling is like AIX & vxfs:

By default the journal log file never contains data. It only contains metadata. The log only gets read when we run #fsck, so journaling can't fix anything beyond what fsck can fix, it just does it faster & more successfully. I once had a student who flipped when he learned this.

Most likely 2 disks won't fail at the same time. As you stated, it took a day to build your RAID5 stuff. So now you should be thinking "will 2 disks fail during that 24 hour period?"

Hardware mirroring is safer than S/W mirroring - with H/W, the host can crash, & you still have the RAID box F/W, yada yada to finish your write. Can your app recover from this? If your app is a DB with redo logs answer = yes. Otherwise better check with your friendly developer.

And finally, until we get #rm -undo we still gotta have B/U's.

Since youv'e been on this thing forever, how would you like me to address your NBU issues? new thread, e-mail?????
 
You must log in or register to reply here.
Back
Top