LVM vs. md: Benefits in RAID0?

I am about to be deploying a new server whose purpose is to replace an existing, aging system. The new server has 2 18GB drives. Once I migrate the user data to the new server, I can reclaim a practically brand new 18GB disk in the old server, bringing the total raw capacity to 18x3 GB.

I installed RH7.1 and was happy to see how easy it was to setup mirroring using the md driver. My plan was to setup 9GB on each disk in a RAID1 config, and then stripe the remaining 9GB on each disk for user data in /home. Then, when I migrated the user data from the old server, I could add the 18GB into /home to give me 36GB for user data. (I want redundancy for the system partitions because as this is a mail server, I do not want the flow of mail to be interrupted during a disk failure. For user data I want to go for raw storage, since I will take full backups nightly.)

In planning the migration, I discovered that md does not allow you to grow. Well, no problem, I know LVM supports this, so I setup LVM to stripe the 2 9GB partitions together. Then, I dropped a 3rd disk in to test the procedure of adding a new disk to the stripe set. I unfortunately then discovered LVM won't let you extend a RAID0 volume, but this is supposedly a planned feature for post-1.0.

I assume the only way to proceed is to use linear concatenation. This lets me extend the volume, but then I don't get the performance gain I'd see with RAID0. But, as I understand the LVM, its advantage is that it lets you resize volumes. Since you can't currently do this in RAID0, does the LVM offer any benefits over md in this situation?

Thanks,
Jason.

--
Academic Computing Support Specialist Assistant Section Editor
Algoma University College http://linux.com/develop
Sault Ste. Marie, Ontario
705-949-2301 x330 Personal Home Page
http://www.auc.ca http://sault.org

The quick and dirty hack to get resizable RAIDed storage devices is:

a) Layer LVM on top of (hard/soft) RAID
b) Layer sotfware RAID on top of software LVM

My tests with _crappy_ hardware show better performance with setup a). It has the added advantage of being able to use hardware RAID, and avoid some layering overhead on the operating system side (there are quite inexpensive SCSI hardware RAID for IDE and SCSI buses out there).

With setup a), you should create one or more RAID devices (depending on type and information to be stored) and then, create a VG from each RAID device. For example, a 3-disk software RAID-5 consisting of 3 10 GB partitions gives you a /dev/md0 20 GB large.

Make a pvcreate /dev/md0, then a vgcreate Group00 /dev/md0 and define LV from this VG (lvcreate -n Group00 -L 5G Volume00). This LV holds your data and avoids loosing them upon a 1-disk failure (RAID-5), and lets you hot-resize the LV (if the filesystem allows it).

Greetings.

--
Jos� Luis Domingo L�pez
Linux Registered User #189436 Debian GNU/Linux Potato (P166 64 MB RAM)

jdomingo EN internautas PUNTO org => � Spam ? Atente a las consecuencias
jdomingo AT internautas DOT org => Spam at your own risk

Hi José, thanks for your reply. I have a few questions:

The problem I see with this is that if you extend the volume group by adding a new partition, the new partition must be linearly concatenated and so it won't be part of the stripe set. So while you can technically extend this configuration, you're not truly resizing the RAID device. Suppose you start off with an md stripe set with sda1 and sdb1, and then later on you want to add sdc1, you get something like this:

<lame ASCII art>

+----------------------------+
|         logical_vol01      |
+----------------------------+
|         volume_group01     |
+-------------------+--------+
|     md0 RAID0     |        |
+-------------------+  sdc1  |
|   sda1   |  sdb1  |        |
+----------+--------+--------+

</lame ASCII art>

So yes, you can extend your logical volume, but you're not extending your stripe set. I guess this has the advantage over linear concatenation in that at least for sda1 and sdb1 you'll get the performance benefit.

I'm just not sure how this would work? You can't extend md devices, as far as I know. So you can extend the underlying logical volume, but then from the RAID layer on top, it just sees one device, so it's not really RAID at all. Can you clarify on this one?

Cheers,
Jason.

What I was thinking about was an underlying RAID0 device with a size greater than the largest LV size you will ever need. I searched through linux-raid archives and I found no reference about whether "extending" stripped RAIDs (0 and 5) is something possible or feasable to do.

My idea was: take 3 40 GB disks, get a 80 GB RAID 0 and create LV and filesystems on demand. Maybe you don't need to store 80 GB worth of data by now, so you have some GB left just in case. Should your dataset ever grows too much, lvextend to a maximun on 80 GB (minus space for the rest of the LV created).

If extending stripped RAIDs is not possible, adding a single drive to the existing VG can impose a bottleneck on R/W speed, so maybe is a matter of generating another stripped RAID similar to the old one, and add it to the VG with a simple vgextend. In this situation you have to be very careful about placing disks and making backups if you want to retain high R/W performance and/or protection on disk failures (for certain RAID levels).

That is, borrowing your "lame ASCII art" ;-), you'll get:

+--------------------------------+
|         logical_vol01          |
+--------------------------------+----+
|         volume_group01              |
+-------------------+-----------------+
|     md0 RAID0     |   md1 RAID 0    |
+-------------------+--------+--------+
|   sda1   |  sdb1  |  sdc1  |  sdd1  |
+----------+--------+--------+--------+

Think about a RAID device made of LVs: you configure /etc/raidtab, write RAID superblocks with mkraid and create a filesystem over md0. Should you need a larger md0 device, put RAID offline, enlarge the corresponding LV and rewrite RAID superblocks on these LV with mkraid -f.

As far as I know, mkraid just generates RAID superblocks, without touching real data (except when you change RAID type :). After mkraid -f, cat /proc/mdstat shows the new size of the RAID device, and you are only a filesystem resize from a larger RAID over LVM.

All of these tried on a test machine, just for the fun of it. I don't have neither the hardware nor the time to test this, with "real" hardware and "real" data. I hope to have both time and hardware to play with on August, when people is on vacation and business is quite low.

Greetings.

Jos� Luis Domingo L�pez
Linux Registered User #189436     Debian GNU/Linux Potato (P166 64 MB RAM)
 
jdomingo EN internautas PUNTO org  => � Spam ? Atente a las consecuencias
jdomingo AT internautas DOT   org  => Spam at your own risk