Pick Your Pleasure: RAID-0 mdadm Striping or LVM Striping?
Given the price of hard drives and the number of drives you can put into a single system albeit a desktop or a server, a very common question is how to arrange the drives to improve performance. Consequently, a somewhat commonly asked Linux storage question that you see on various mailing lists is, which is better for data striping, RAID-0 with mdadm or LVM? While many people will correctly point out that this argument is somewhat pointless because each is really intended for different tasks, the question is still fairly common. Nonetheless, in the quest for the best performance possible, there is still the question of which one is better (whether it's meaningless or not). In this article both concepts will be contrasted in regard to performance with some discussion about appropriateness. To add at least a little chaos to the situation, some simple IOzone benchmarks with RAID-0 and LVM will be presented.
Data striping is a commonly used technique for improving performance. It breaks data into pieces that are assigned to various physical devices, usually storage devices, in a round-robin fashion. One of the reasons that this concept was developed is that processors are capable of generating IO (reads and writes) much faster than the storage device can store or recall it. But if you can split the data among multiple storage devices then you can perhaps improve IO performance.
The process is very simple. In the case of a write function, the incoming data is split into pieces with the first piece being sent to the first device, the second piece being sent to the second device, and so on until all the devices have received a data piece or all the data has been written. If there are still pieces of data to be written then the next piece is sent to the first device and the process continues (round-robin). Data throughput is improved because the system can send one piece of data to one storage device and immediately move on to the next piece of data and the next storage device without having to wait for the first one to complete. If you like, the data storage is parallelized. In Linux there are two primary ways to achieve this, RAID-0 and LVM.
RAID-0 with mdadm
One way to achieve data striping is to use RAID-0. Most people are probably familiar with the concept of RAID (Redundant Array of Inexpensive Disks) that seeks to divide data, possibly replicate it, and place it on storage devices. There are various techniques to achieve these goals and each one has a number associated with them such as RAID-0 or RAID-1. These details of the scheme define whether the emphasis is on either data reliability or increased throughput or possibly both.
RAID-0 is a scheme to improve data throughput by taking the data and spliting it evenly between multiple disks (data striping). Figure 1 below, from Wikipedia, shows how data is split across two disks.
In this example, the first data piece, A1, is sent to disk 0, the second piece, A2, is sent to disk 1, and so on.
There are two terms that help define the properties of RAID-0.
RAID-0 can, in many cases, help IO performance because of the data striping (parallelism). If the data is smaller than the stripe size (chunk size) then it will be written to only one disk not taking advantage of the striping. But if the data size is greater than the stripe size, then read/write performance should increase because of the ability to use more than one disk for a read or write. Increasing the stripe width adds more disks and can improve read/write performance if the stripe width (chunk size) is greater than the data size.
Mdadm is an all-purpose RAID management tool for Linux with a long history.
LVM has been discussed in a previous article about managing pools of data. As discussed, it is an extraordinary useful tool for managing storage. Fundamentally it allows you to collect physical storage devices and combine them into virtual devices (volume groups) that can be divided into logical partitions (logical volumes) that are then used as the device for file systems. You can add or subtract devices from the virtual devices (volume group) or even move them as needed. Coupling these techniques with file systems that can be resized and you have a terribly efficient way of growing or moving file systems as needed.
In addition, LVM is very flexible allowing you to control exactly how the physical devices are combined into the volume groups (VGs) and the logical volumes (LVs). It is this flexibility that allows you to do data striping. In LVM this is called striped mapping. Figure 2 below illustrates this concept.
Striped mapping maps the physical volumes (typically the drives) to the logical volume that is then used as the basis of the file system. LVM takes the first few stripes from the first physical volume (PV0) and maps them to the first stripes on the logical volume (LV0). Then it takes the first few stripes from the next physical volume (PV1) and maps them to the next stripes in LV0. The next stripes are taken from PV0 and mapped to LV0 and so on until the stripes on PV0 and PV1 are all allocated to the logical volume, LV0.
The advantage of the striped mapping is similar to RAID-0. When data is read from or written to the file system and if the data is large enough, it spans multiple stripes so that both physical devices can be used, improving performance.
Contrasting RAID-0 and LVM
From the previous discussions it is obvious that both RAID-0 and LVM achieve improved performance because of data striping across multiple storage devices. So in that respect they are the same. However, LVM and RAID are used for different purposes, and in many cases are used together. Let's look at both techniques from different perspectives.
The size (capacity) of a RAID-0 group is computed from the smallest disk size among the disks in the group, multiplied by the number of drives in the group. For example, if you have two drives where one drive is 250GB in size and the second drive is 200GB, then the RAID-0 group is 400GB in size, not 450GB. So RAID-0 does not allow you to use the entire space of each drive if they are different sizes.
On the other hand, LVM allows you to combine all of the space in all of the drives into a single virtual space. You can use stripe mapping across the drives as you would in RAID-0, with the capacity being the same as RAID-0. However, LVM allows you to also use the remaining space for additional volume groups (VGs).
In the case of mdadm and software RAID-0 on Linux, you cannot grow a RAID-0 group. You can only grow a RAID-1, RAID-5, or RAID-6 array. This means that you can't add drives to an existing RAID-0 group without having to rebuild the entire RAID group but having to restore all the data from a backup.
However, with LVM you can easily grow a logical volume. But, you cannot use stripe mapping to add a drive to an existing striped logical volume because you can't interleave the existing stripes with the new stripes. This link explains it fairly concisely.
Despite not being able to maintain a striped mapping in LVM, you can easily add space to a strpped logical volume.
This article, written by the original developers of LVM for Linux, present four advantages of LVM.
These four advantages point to the fact that LVM is designed for ease of management rather than performance.
Performance Comparison of RAID-0 and LVM Striped Mapping
The previous section contrasted RAID-0 and LVM from a conceptual perspective, but the question of which one is faster still remains (even if the question isn't a good one). This section will present a performance comparison of RAID-0 using mdadm and LVM. However, in the interest of time it doesn't follow our good benchmarking guidelines (a full set of benchmarks would take over 160 hours). In this case IOzone is used as the benchmark.
IOzone is run in two ways: (1) Throughput, and (2) IOPS. Also, only the write, read, random write, and random read tests are run but a range of record sizes will be tested. Unlike tests from previous articles, each test was only run 1 time using ext4. The test system used a stock CentOS 5.3 distribution but with a 2.6.30 kernel (from kernel.org) and e3fsprogs was upgraded to the latest version as of the writing of this article, 1.41.9. The tests were run on the following system:
Both drives, /dev/sdb and /dev/sdc, were used for all of the tests.
To help improve run times, 3 threads were used on the quad-core system. The fourth core was kept for the software RAID or LVM processing. So in the IOzone command lines the "-t 3" option means that three threads were used. In addition, each thread had a size of 3GB, resulting in a total data size of 12GB. The important point is that the total amount of data is larger than memory (12GB > 8GB).
For the throughput tests, the following IOzone command line was used.
./iozone -Rb spreadsheet_ext4_write_and_read_1K_1.wks -i 0 -i 1 -i 2 -e -+n -r 1k -s 3G -t 3 > output_ext4_write_and_read_1K_1.txt
The command line is shown with a 1KB record size.
The IOPS tests used the following IOzone command line.
./iozone -Rb spreadsheet_ext4_write_and_read_1K_1.wks -i 0 -i 1 -i 2 -e -O -+n -r 1k -s 3G -t 3 > output_ext4_write_and_read_1K_1.txt
The RAID-0 array was constructed relying on defaults as shown in a previous article. The command used to construct the array was the following.
[root@test64 laytonjb]# mdadm --create --verbose /dev/md0 --level raid0 --raid-devices=2 /dev/sdb1 /dev/sdc1
The "chunk size", or stripe width, defaults to 64KB.
To contrast RAID-0 and LVM they need to be constructed as similarly as possible. This is a bit more difficult in LVM since it is different than RAID. The basics of LVM were discussed in a previous article. After the physical volumes (PV's) were created they were grouped into a single volume group.
[root@test64 laytonjb]# /usr/sbin/vgcreate primary_vg /dev/sdb1 /dev/sdc1 Volume group "primary_vg" successfully created [root@test64 laytonjb]# /usr/sbin/vgdisplay --- Volume group --- VG Name primary_vg System ID Format lvm2 Metadata Areas 2 Metadata Sequence No 1 VG Access read/write VG Status resizable MAX LV 0 Cur LV 0 Open LV 0 Max PV 0 Cur PV 2 Act PV 2 VG Size 931.52 GB PE Size 4.00 MB Total PE 238468 Alloc PE / Size 0 / 0 Free PE / Size 238468 / 931.52 GB VG UUID yjkNSQ-416l-f5Bt-RZLt-38NH-8LT6-QfrjeJ
The key to stripe mapping in LVM is how the logical volume is created. For this article the number of stripes ("-i" option) was arbitrarily chosen to be 2, and the stripe width ("-I" option) was chosen to be 64KB to match RAID-0. The total size of the LV was arbitrarily chosen to be 465GB. The command line for creating the LV was the following.
[root@test64 laytonjb]# /usr/sbin/lvcreate -i2 -I64 --size 465G -n test_stripe_volume primary_vg /dev/sdb1 /dev/sdc1 Logical volume "test_stripe_volume" created [root@test64 laytonjb]# /usr/sbin/lvdisplay --- Logical volume --- LV Name /dev/primary_vg/test_stripe_volume VG Name primary_vg LV UUID igTRtk-wcqn-YVzR-HNQh-Ki2b-HznC-HcW589 LV Write Access read/write LV Status available # open 0 LV Size 465.00 GB Current LE 119040 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 512 Block device 253:0
Then the file system is created using the logical volume test_stripe_volume.
[root@test64 laytonjb]# /sbin/mkfs -t ext4 /dev/primary_vg/test_stripe_volume mke2fs 1.41.9 (22-Aug-2009) Filesystem label= OS type: Linux Block size=4096 (log=2) Fragment size=4096 (log=2) 30474240 inodes, 121896960 blocks 6094848 blocks (5.00%) reserved for the super user First data block=0 Maximum filesystem blocks=4294967296 3720 block groups 32768 blocks per group, 32768 fragments per group 8192 inodes per group Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 102400000 Writing inode tables: done Creating journal (32768 blocks): done Writing superblocks and filesystem accounting information: done This filesystem will be automatically checked every 21 mounts or 180 days, whichever comes first. Use tune2fs -c or -i to override.
RAID-0 and LVM Test Results
The two tables below present the throughput and IOPS results for both RAID-0 and LVM. Table 1 contains the throughput results.
Table 1 - Throughput Tests
Table 2 below contains the throughput results for both RAID-0 and LVM.
Table 2 - IOPS Tests
Even though the results did not follow our good benchmarking habits, which really limits our ability to make any conclusions, it is interesting to do a quick comparison.
A fairly common question people ask is whether it is better to use data striping with RAID-0 (mdadm) or LVM. But in reality the two are different concepts. RAID is all about performance and/or data reliability while LVM is about storage and file system management. Ideally you can combine the two concepts but that's the subject of another article or two.
In the interest of trying to answer the orignal question of which one is better, a quick test was run with IOzone. We did not use our good benchmarking skills in the interest of time, but the test results give some feel for the performance of both approaches. The performance was actually fairly close except for small record sizes (1KB - 8KB) where RAID-0 was much better.