(Note: I’ve gone back and forth about posting this article. I really am not an expert in this area and I don’t want to advise people to do something stupid. OTOH, this is something that I’ve never seen described before. I’ve decided to post it, but it’s probably best treated as a curiosity, not a data storage strategy.)

Let’s do a little Linux magic. We’re going to create a RAID 1 (mirrored) pair, transform it to a 2-disk RAID 5 array (you know, the kind that “requires” 3 or more disks), then grow it to a 3-disk RAID 5 array.

Just so nobody gets too confused, I’m using a fairly fresh install of Ubuntu 6.06 Dapper Drake, which includes EVMS 2.5.4.

Now we’re ready to work in evms. Launch the NCurses interface to evms with the command evmsn. Our first step is to delete the “compatibility volumes” that evms automatically creates for us. Select Actions > Delete > Volume (by typing a d v) and select all of the /dev/evms/loopX volumes listed (using the space bar and arrow keys). Don’t select anything else that might be listed! Hit enter to go ahead with the deletion. The dialogs that you’ll see next are not important for our purposes — just chose the defaults until you get back to the evms interface and see the message “The Delete command(s) completed successfully.” at the bottom of the screen.

Next, we will build our first RAID, a level 1 mirrored pair. Select Actions > Create > Region, select the MD Raid 1 Region Manager, and hit enter. Now select loop0 and loop1 and hit enter. Leave the configuration options alone, hitting enter once more to create the Raid region. You’ll get a congratulatory message that informs you that the storage object md/md0 has been produced.

Now if this were a real storage array we were building we would probably put an LVM2 container on top of md0 and create some logical volumes, but in this tutorial we’re just going to create a volume from md0 directly.

Select Actions > Create > EVMS Volume, select md/md0 and give the volume the name RaidVol. Hit enter to go through with the creation. Now we should see /dev/evms/RaidVol in the list of logical volumes.

Let’s put a filesystem on it, so we can save some test data to the volume. Select Actions > File System > Make, select Ext2/3 File System Interface Module, and hit enter. Now choose RaidVol and hit enter twice to finish up with the default configuration options.

At this point your logical volumes list (hit zero to show it if it’s not there already) should look something like this:

EVMS is a cautious system and doesn’t actually change anything until you save your changes. At this point we need to save our progress, so select Actions > Save. Once you’ve saved your changes you can mount your shiny new volume! Select Actions > File Systems > Mount and mount RaidVol at /mnt/raidvol. We’re done with evmsn for the moment, so select Actions > Quit.

It’s easy for me to tell you this works, but if you want to have confidence in this procedure you’ll want to verify it for yourself. Copy some files to /mnt/raidvol — images, text files, whatever. Try to fill up the drive as completely as possible. (Hint: One way to fill it up is dd if=/dev/zero of=/mnt/raidvol/zeros) Once you’ve filled the disk, run md5sum on your files:

Now we’re ready to start making magic. (Hint: You might want to back up img0 and img1 now so you can skip many of the previous steps if you want to experiment in the future.) Launch evmsn once more. Unmount the volume with Actions > File System > Unmount.

We’re going to be doing some things behind the back of evms, so let’s convert the volume to a “compatibility volume” with Actions > Convert > EVMS Volume to Compatibility Volume. Save your changes and quit.

The next bit is somewhat voodoo. It’s based on the semi-obscure fact that the RAID 5 algorithm can indeed be applied to two disks, and when you do so the disks end up mirrored! This works because the parity of a single block is equal to the block itself, though the normal way of setting up RAID 5 arrays involves computing the parity of at least two blocks. As a consequence, the only difference between a 2-disk RAID 1 pair and 2-disk RAID 5 array is the metadata! By rewriting the RAID metadata, we can instantly convert our array to RAID 5.

We’re going to use mdadm to rewrite the RAID metadata. First we’ll need to stop the array:

# mdadm --stop /dev/evms/md/md0

Now we’re going to “create” a RAID 5 array using our existing loopback devices. In effect, this should just change the metadata and give us a functional array. mdadm is going to get suspicious, but it’ll let us proceed:

You should get a list of messages that the procedure has produced, and, with luck, none of them should be error messages! Choose cancel to dismiss the dialog, and notice that RaidVol is now 20MB! Mount the volume (Actions > File System > Mount), quit evmsn and let’s make sure everything is ok:

Nifty, eh? Now before you run down to your data center and try this procedure on your client’s drives, you should be aware that I’m pretty clueless about all this stuff and there may very well be extremely good reasons not to do this. If you do attempt it, make sure you have recent backups, and don’t say I didn’t warn you!

Nice… Just one small tip which was handy when I had to recustruct LVM with failed PV (which was not mirrored).
It allows you to create loopback devices bigger than your RAM. Suppose you need to simulate 160 GB HDD. You can create it in RAM even when booted from Live CD.
# dd if=/dev/zero of=/dev/shm/file1 bs=1M seek=10240 count=1

This command will create a 10 GB file, which will need only 1 MB of RAM. What this command does, is create a sparse file – nothing is allocated except last 1 MB of data, so only 1 MB of RAM is used. You can then vgcfgrestore PV headers on it – and used RAM will grow only by the amount of data you write to the file.

Dude, that’s some nifty magic and it was certainly insightful. I had no idea that checksum(1 disk) = 1 disk.

Anyway, it is so much easier to just create the raid 5 on two disks instead of all this trickery. The added benefit is that you can grow it online (especially with SATA disks that can also be hotplugged).

Great artikel.
I wonder if it would be possible to revert the procedure. I have 2 disks running in raid5 as you converted it to. It’s used in a Xen System which has a quite slow i/o performance. Now I want to try to convert back to raid1. As I understood this should also be possible with a similar procedure? I hope to get some more i/o performance.

Tested it with the images and the loop devices. The reverse procedure also works! Same complaints from mdadm but no probs when confirming with yes. Before going on to the real system. Do you think there will be a noticeable performance gain in I/O when reverting back to raid1? On top of raid I have LVM. I could already gain a heavy performance increase via converting the the virtual machine images to “raw” format. This gives a real performance boost. There is a huge performance loss when using standard virtual image format on top of LVM.

Just wanted to test it but… The f.. LVM sits on top of it and I do not have a spare disk at hand. I am not able to stop the raid device because LVM holds it. What I need is the functionality of LVM OLR but that seems not to be possible with linux lvm. Is there any chance to remove a device from a volume group with keeping all data and LVs intact such that it can be readded? Maybe someone has an hint.