From my experiment under debian Lenny, using virtual disk made from /dev/zero, the result should be the sum of every disk of the group, which is exactly the same to lvm2. I made 2 virtual disks of 3Mb and 6Mb, the result capacity of raid0 is 9Mb, rather than 6Mb.

BTW, The mdadm version is v 2.6.7.2, linux kernel 2.6.26

My usual setup is to use hardware RAID (usually 0+1 for small installation and 5 for larger datasets), generally with an HP SmartArray controller (PERC if Dell but I don\’t use Dell often), and then use lvm on top of that to provide maximum flexibility.

With battery backup, ie such as your PERC/HP Smart Array, the performance goes through the roof (perhaps 10x the IO/s in some cases) simply because the card \”lies\” and says that the data has hit the disk when it\’s really still in disk cache. However, the card can aggregate the data, batch the writes, reorder the writes to minimise disk seeks and generally vastly improve write speeds (it should have little effect on read speeds)

Without battery backup the hardware cards should make little difference either way (I\’m sure any given test will show one better than the other mind). There is simply no reason for hardware to win over software in general purpose use (lets assume less than 16 hard drives and ignore super large arrays, etc) Fundamentally the read speed is set in stone, with perhaps a small amount of re-ordering possible to improve things, the write performance can be vastly improved by re-ordering and batching things, but re-ordering writes is simply not possible without a BBU (or at least not safely).

So in general the cheaper hardware cards are of little value other than ease of setup (and the really cheap cards are usually actually software raid via a custom driver…) And the expensive hardware cards will set your world on fire, but by definition they are expensive..

I have used the HP Smart Array cards many years ago and for our database application they gave us at least a 10x speedup in IO/s simply by flicking the writeback cache on/off… Stonking units

Obviously, when write cache is enabled for the controller (as it should to have a real performance benefit), you suffer the risk of data corruption when power is lost to the device.

You are talking about PERC and SmartArray as if it has battery backup by default. This is obviously not the case for either of these, or any other hardware raid card for that matter. This is sold seperately, and available for any major brand.

I can assure you, most users use the write cache even without the battery backup. Datacenters are quite reliable these days you know…

\”The performance was actually fairly close except for small record sizes (1KB – 8KB) where RAID-0 was much better.\”

Like that doesn\’t count? for the 1K Read (KB/s) it was about a 32% increase. I know that most files are not that small. I think that if the OS was raided it would further magnify this difference. The size and dependability of today\’s drives minimizes the need for LVM.

Write throughput is pretty flat starting at 8KB blocks. Random reads and writes show a steady improvement with larger blocks. Is this because the random access negates the benefit of Linux\’s disk cache?

Even though it would have been outside the article\’s topic, I would like to see the results of a non-striped test on the same hardware to show how much benefit there is from striping, whether RAID-0 or LVM.

I fixed the raid-1 goof. Thanks for the catch typhoidmary. I checked the system and it was RAID-1. The raid-1 in the command line was a typo.

Jeff

You fell into the trap :) The benchmarks were only single runs, consequently there is no measure of variability in the runs. So 30% might be a huge difference, but the variability could be larger than that. The problem is that we don\’t just know. So it makes it difficult to compare (actually I think it\’s impossible).

But I included the results for fun.

Jeff

a) CPU usage will be smaller (mainly with ATA/SATA disks)
b) bandwidth – the HW controller is, in principle, capable of comunicating independently with the disks and providing full speed (limited by the bus) to the chipset

According to the lvcreate manpage, the “-i” option indicates across how many physical volumes (within the volume group) to scatter the logical volume. Hence, in your case, the number “2″ that you gave to “-i” is not arbitrary at all. In fact, this is the only number that makes sense, since you had two physical volumes in your volume group.

Here is the relevant part of the manpage:

-i, –stripes Stripes
Gives the number of stripes. This is equal to the number of physical volumes to scatter the logical volume.

Thanks,
Iordan