Re: RAID5 gets a bad rap

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Philip A. Prindeville wrote:
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?

You should really read the linux-raid mailing list for a while and look at the benchmarking done and reported there by many people who have been doing this for a while. Clearly there are many performance issues you don't know about.

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

Based on benchmarks done by many people your results don't match ours. RAID5 write is slow because of the way it's done in the md code, and unless you are testing on a minimal size array (2-3 drives) this should be obvious. Both RAID0 and RAID10 outperform significantly.

Ditto with reading lots of files.

Sustained read should be N-1 times the speed of a raw disk.

The advantage of RAID5 is that it's the cheapest way (in disk count) to have redundancy.

--
Bill Davidsen <davidsen@xxxxxxx>
  "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot

--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora Magazine]     [Fedora News]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [SSH]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux