RAID5 gets a bad rap

[Philip A. Prindeville]

I was going back over the archives and saw a lot of people complaining 
about how slow RAID5 was, and did some quick research into this.

Yes, it's true that it can be slowed down if you're rewriting 
fragmentary data in place, since this takes a read-modify-write operation.

But that's true of most filesystems.

If you're *not* a database weenie, and you're doing usual manly things 
with your filesystem (like lots of compiles, for instance), you're 
typically not going to be modifying files in place at all.

You're going to either be writing out new files, or else opening 
existing files for writing, doing a truncate(fd, (off_t) 0) on them, and 
then writing them out, etc.

Or else you're going to be opening lots and lots of files for reading...

Both of which RAID5 does as well as the next thing (which would be RAID0).

Why?  Because if you're writing out files, you don't need to 
read-modify-write, you can just write (and write the stripe parity data 
at the same time).

"Ok, sure, you say, but what about the 16K (or whatever) stripe size 
versus writing data out in smaller chunks?"

Yes?  What about it?  You might be writing blocks out via stdio 
buffering in 4K chunks or whatever, but unless you're doing a sync() 
after every single write (buffer flush), the filesystem (ext3 or 
whatever) is free to accumulate consecutive blocks into handy (read: 
more efficient) chunks (such as multiples of the stripe size) and write 
them out all at once... again eliminating the need to do a 
read-modify-write (since you only need to do a read-modify-write if 
you're writing incomplete blocks).

So is it just the database-heads that are maligning RAID5, or are there 
other performance issues I don't know about?

Because my empirical experience has always been that when writing large 
files, RAID5 performs on par with RAID0.

Ditto with reading lots of files.

-Philip