Converting RAID1 array to RAID5 using the mdadm grow command

I have finally decided to upgrade the storage in the home theatre PC, by adding a third 3TB hard drive. The storage was set up previously as RAID 1, using the software mdadm solution for the two 3TB disks. By adding a third drive and changing to a raid 5 format, the storage would increase from 3TB (about 2.7TiB) to 6TB (about 5.4TiB).

There are a few ways to do this:
1. Copy the data to a spare drive, delete the RAID 1 array, create the RAID 5 array with the three disks, copy the data back to it.

2. Back up the data to a spare drive, remove one disk from the RAID 1 array, use that disk and the new disk to make a 2 disk RAID 5 array, copy data over, remove the RAID 1 array and add that disk to the RAID 5 array so it is 3 disks.

3. Back up the data to a spare drive, Use the mdadm --grow command to change the RAID level from RAID 1 to RAID 5, add the third drive to the RAID 5 array and let it rebuild.

Initially I was going to try option 2, such as described here. But noticing one of the comments (by the wonderfully named Svenne Krap) describing that you can just change the level of the array using the mdadm grow command, I thought it would warrant further investigation. I couldn't find many other mentions of it elsewhere on the internet, so I thought I'd document what I'd done so it might help someone else.

So to try it out, I set up a virtual machine on another PC, and created three separate drives. I used mdadm to create a RAID 1 array with two of them, and then converted that array to RAID 5. It worked! I then added the third drive, and after a little while it rebuilt into a full three disk array.

So the time came to do it for real. I first wanted to back up the array - and found an old 2TB drive lying around. Fortunately, the array was only just over two thirds full, so it all managed to squeeze on to the 2TB drive after I deleted a few old TV shows. That's still nearly 600 TV shows and movies left - I have no idea when I'll get around to watching them all, but it's nice to have.

So the data was safe. I could do this switchover with a little less stress.

One thing I noticed with the options was chunk size. Different sizes give different performance. Since this box would be primarily a media box, reading and writing large video files, I went for a larger chunk size of 512KB. When creating the array in the virtual machine initially, it created only 4KB chunks as the size of the array was not a multiple of 512KB. So first up, I resized the RAID 1 array so it was. Basically I divided the size reported by the cat /proc/mdstat command, by 512. It gave a number ending in .625, meaning there weren't an exact number of 512KB chunks. By multiplying that answer (minus .625) by 512, it gave a size that could work.

So I resized the array with the following command:

sudo mdadm -G /dev/md0 --size=2930266112

I then let mdadm know about the new drive, by adding it. The new drive is /dev/sde:

sudo mdadm /dev/md0 --add /dev/sde

Now there was a third drive added as a spare to the array, but not actually in use by it yet.

Next, the big one, change the array from RAID 1 to RAID 5 (still only 2 drives):

sudo mdadm /dev/md0 --grow --level=5 --chunk=512

The array is now a RAID 5 array, with two disks. The chunk size of 512KB was also set with that command. Time to let it use the third drive to create the full, three disk RAID 5 array:

sudo mdadm --grow /dev/md0 --raid-devices 3

This kicks off the rebuilding process, which takes many hours. You can track the progress with the cat /proc/mdstat command. It ran pretty slowly on my system, at around 30,000KB/sec, until it got to the empty part of the array, when speed nearly tripled.

Later that day, the process was finished. Running sudo mdadm --detail /dev/md0 gave the new array size of about 5.4TiB - something I was a little concerned about while the rebuild was underway, because it was only showing the old size of less than 3TB. I thought I might have to resize the array afterwards, but it all came out good.

Resizing LVM

Because I was running LVM on top of the raid array, the size of the LVM volume was still unchanged - I had to increase that to let it use the extra space that was now available. Going by the size reported by the mdadm --detail command run previoulsy, there were approximately 5588GB in the array. LVM works with three 'layers' - the physical volume, basically the hard drive or RAID array; volume groups, which consist of a number of logical volumes. See here for more information. The first step is to resize the physical volume to match the size of the array:

sudo pvresize --setphysicalvolumesize 5588G /dev/md0

Next, I could extend the logical volumes to use up more of that space. I have two main logical volumes on this volume group: one called 'tv' that holds TV shows, movies, and music from MythTV, and another called 'sysbackup' that holds backups of data. I wanted to enlarge both of these - the 'tv' one, and also 'sysbackup' because I wanted to use it with Crashplan as a backup destination for some other PCs in the house.

I wanted to increase the 'sysbackup' volume to 1.2TB, so I used the following command:

sudo lvextend -L1.2T /dev/raid1/sysbackup

A couple of things to note here: the '-L1.2T' instructs it to make the total size of the volume 1.2 Terabytes. Also, the name of the volume group is still /dev/raid1 - I haven't changed the name of that, even though it is now RAID 5. It can be done with the vgrename command, but it would also mean changing mount points in the /etc/fstab file.

Next was the resizing of the 'tv' volume. I wanted to increase it by 1.6TB, so I used the following command:

sudo lvextend -L+1.6T /dev/raid1/tv

Notice the '-L+1.6T' - the plus sign commands it to expand the volume by the specified amount. Unfortunately, it reported that there wasn't 1.6TB spare, and gave a number of available extents that were free. So I tried a different approach, specifying size in extents rather than TB:

sudo lvextend -l+418800 /dev/raid1/tv

The lower-case 'l' instructs it to use extents rather than GB, TB or whatever. This worked, and I now had two newly-resized logical volumes.

Resizing the file systems

But there was one final step - the logical volumes were now bigger, but the file systems did not know about it yet. Fortunately it isn't too difficult.

The sysbackup volume was formatted with the ext4 file system. To resize that, it first had to be unmounted:

sudo umount /mnt/sysbackup

Then a check of the file system was done:

sudo e2fsck -f /dev/raid1/sysbackup

Then finally, the file system was resized to fill the available space:

sudo resize2fs /dev/raid1/sysbackup

Finally, the file system can be re-mounted. Since it is specified in the /etc/fstab file, running

sudo mount -a

did the trick. Next was the 'tv' volume. This volume was formatted with the XFS file system, and it can be resized while still mounted. The command for that was:

sudo xfs_growfs /dev/raid1/tv

Conclusion

The advantage of using the mdadm --grow command is that it is still the same array according to mdadm, just a different level. Running

sudo mdadm --detail --scan

shows that the array still has the same identifiers as when it was a RAID 1 array, so no further work is required. I ran

sudo update-initramfs -u

just in case, so it would pick up any changes in the array (and not give it a name like /dev/md127 after a reboot). I restarted the PC, and everything came back up, with the roomy new array showing up as it should. Done!

HTPC update - separating backend from frontend

After using the Atom-based HTPC for a while, I noticed it start to struggle in high load situations - like playing back HD TV while recording multiple streams, commercial flagging, trying picture-in -picture, running disk checks. I decided to upgrade the box to something a bit more powerful, so there’s a bit more headroom.

So a while back I picked up an AsRock H77-M motherboard, with a cheap Pentium G2020 CPU. 4GB of RAM was sitting around idle after a previous desktop PC upgrade, so in that went. Two, 3GB drives were installed, still in a RAID-1 configuration. The OS was installed on an SSD that was left over. Graphics were handled by an Nvidia GT630 card, made by ASUS. I chose that one because of the passive cooler, and the fact that it is quite power efficient for what it does. A TP-Link wireless card was put in so it could see the network.

For the operating system, I went with Mythbuntu 12.04 again. Installation went pretty straightforward. No real problems, TV listing data was handled by the excellent shepherd - that just does its own thing, causing very little trouble.

Playback worked beautifully on this machine - it handled everything I could throw at it. However, my curiosity was getting the better of me, so I dug out the old Atom box and reinstalled mythbuntu, this time running just as a frontend. That made quite a bit of difference - without all the overhead of doing all the database tasks, flagging commercials and the like, it ran beautifully.

Since I had recently had some network cabling installed in the house, I tried running the new box as a backend only, up in the study, with just the Atom frontend in the lounge. Without any worries about wifi dropping out, the nice fast, stable wired network connection supplied data from the backend nicely.

It ran like that for a while, but then I started thinking that there are now three points of failure instead of one. Where previously there was just the Pentium backend/frontend to troubleshoot, there was now also the frontend box, plus the router that could cause problems. Eventually I put the frontend box back away.

I’m not sure what made me do it, but soon after getting a new TV (LCD! HDMI inputs! No more fooling around with xorg.conf and custom modelines and VGA to Component transcoders!) I wanted to clear out a bit of clutter from the lounge room. Moving the big box meant I could get rid of a whole heap of things from the lounge - the UPS, the transcoder (not needed any more), the aerial connection with splitter and the external TV tuners. All of the bulky component cables are no longer needed, either, replaced by a single HDMI cable.

So up to the study the box went, along with all the tuners and UPS, but they have been tucked away behind the desk, out of sight. The lounge room now just has a power cable to the frontend box, a network cable, an optical cable to the receiver, and the HDMI cable to the TV.

For now, I’m just rebooting the router every few weeks, or whenever there is some sort of issue like PCs not being able to access the internet. A lot of data is now going across it with TV viewing.

The backend box was able to have the graphics card removed from it, as it is now running headless. I only connect to the machine via ssh. That has saved a bit of power consumption. Another change made to the backend box has been to add a second SSD, to run the OS off a RAID-1 array. This way, a drive failure will not stop the machine. It will run in a degraded state until a new one can be installed.

I did the same with the frontend box - a couple of old laptop drives were pressed into service for that. Both are pretty elderly, but since they are in RAID-1, unless they both die at the same time, it should be safe. And really, it’s only a frontend, it wouldn’t be too much of a hassle to rebuild it from scratch if needed. I’m considering replacing those drives with a couple of USB sticks, to further reduce power consumption.

For the backend box, disk usage is sitting at around 65%. I’ve been copying some of my DVD library to the server, just to avoid dealing with physical discs. I don’t actually have a DVD drive in the frontend, anyway. If space gets tight, I might need to expand storage. I’m toying with getting a third 3TB drive, and converting the system to either RAID-5, or going a bit radical and putting ZFS on Linux back on it. My only concern with that is that it can have issues with fragmentation, and my PC doesn’t use ECC RAM. A lot of memory is also used for caching purposes with ZFS.

One thing I am wondering about with my current XFS file system is to do with fragmentation. I currently have a cron script to defragment it nearly every morning. Not sure what the deal is with RAID-5, and how it deals with fragmentation. Might just have to try it and see, when I get around to it. Might just go with ext4 for the file system. Outright performance isn’t so much of an issue for this machine - video recording and playback isn’t pushing it too much.