RAID5 gets a bad rap
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