Re: RAID5 gets a bad rap

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

 



On Tue, 2008-12-30 at 01:02 -0800, Gordon Messmer wrote:
> Philip A. Prindeville wrote:
> > 
> > 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.
> 
> That's not quite it.  RAID 5 performance suffers because every write 
> requires that the entire block that's being written be read from every 
> drive in the array, parity calculated, and then the data and parity 
> written out.  For each block written, the array has to do N reads plus 
> two writes.

You don't have to read all of the drives -- just the block you're
updating and the parity block. XOR the old data you're about to
overwrite with the parity block and the new data and you'll have the new
parity block. Total activity: two reads plus two writes.

But that's the worst case. The OP's point is that you don't need to do
any reads if you're writing enough sequential data to fill N-1 blocks --
e.g., in a 5-drive array, with a 4k block size, writing 16k of data
(four 4k blocks in the same parity stripe) can be done without any
reading at all -- just 5 writes. If each drive is on a separate
controller, those writes can be done in parallel. For multi-megabyte
writes, this scenario is very common. (For a 32k block size on a 5-drive
array, you'd need to write 128k for a readless update).


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

Exactly.


> RAID 5 tends to be most appropriate when you're trying to get as much 
> disk space as you can with the lowest cost, you won't be running 
> multiple simultaneous jobs on the same disk array, and when you'll be 
> collecting data at a rate that's relatively low.

I'd say the other way around -- RAID 5 is poor at small writes (hence
the OP's comments about database updates), but very nearly approaches
RAID-0 speeds when reading or writing large quantities of sequential
data.

-Chris

-- 
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