You are here

HowTo: RAID1 auf RAID5 migrieren

As I wrote last week (German), I had the plan to make a RAID5 out of my existing RAID1 after I received my third 1 TB harddisk. Migrating to RAID5 doesn't work online yet, because mdadm doesn't support the use of --grow and --level together, as you can read in the man page when looking for "-l, --level":

-l, --level=
Set raid level. When used with --create, options are: linear, raid0, 0, stripe, raid1, 1, mirror, raid4,
4, raid5, 5, raid6, 6, raid10, 10, multipath, mp, faulty. Obviously some of these are synonymous.

When used with --build, only linear, stripe, raid0, 0, raid1, multipath, mp, and faulty are valid.

Not yet supported with --grow.

But there's always a way to obtain your goal. If you're brave enough you can find the solution by a quick internet search. Ok, I'm not that brave to try this without a backup, but you shouldn't do that kind of work without having a good backup anyway.

But before I describe the way how to do it, as usual a strong disclaimer: use this howto on your own risk! There's no warranty that this will work for you and you should take care to have a backup of your data. Whoever is doing this migration without having a backup risks the loss of all the data!

I'll describe the migration using an example... there are three logical volumes (LVs) with 1 GB in size each. This is enough for testing purposes and demonstrates how the migration works. You can use real partitions like swap partitions if you want. The LVs are r1, r2, and r3 and are within the Volume Group (VG) /dev/vg:

r1 vg -wi-a- 1.00G
r2 vg -wi-a- 1.00G
r3 vg -wi-a- 1.00G

Two of these LVs are being setup for a RAID1 /dev/md5:

[code]
muaddib:/home/ij# mdadm --create /dev/md5 -l 1 -n 2 /dev/vg/r[12]
mdadm: /dev/vg/r1 appears to be part of a raid array:
level=raid1 devices=2 ctime=Thu Feb 26 16:16:59 2009
mdadm: /dev/vg/r2 appears to be part of a raid array:
level=raid1 devices=2 ctime=Thu Feb 26 16:16:59 2009
Continue creating array? yes
mdadm: array /dev/md5 started.
[/code]

The warning to be a part of another raid array can be ignored. It's just a testing array. The result should look similar to:

md5 : active raid1 dm-12[1] dm-11[0]
1048512 blocks [2/2] [UU]
[========>............] resync = 40.2% (422900/1048512) finish=0.7min speed=14096K/sec

Now a filesystem can be created on the raid array and some data can be stored there:

[code]
muaddib:/home/ij# mkfs.xfs -f /dev/md5
meta-data=/dev/md5 isize=256 agcount=4, agsize=65532 blks
= sectsz=512 attr=2
data = bsize=4096 blocks=262128, imaxpct=25
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0
log =internal log bsize=4096 blocks=1200, version=2
= sectsz=512 sunit=0 blks, lazy-count=0
realtime =none extsz=4096 blocks=0, rtextents=0
muaddib:/home/ij# mount /dev/md5 /mnt
muaddib:/home/ij# cp pics/backdrops/*.jpg /mnt/
muaddib:/home/ij# dir /mnt/
amigager_back1.jpg Dansk-Dunes14.jpg Dansk-Nature-2.jpg
CapeCod_085.jpg Dansk-Dunes15.jpg Dansk-Priel.jpg
ct-1-p1600.jpg Dansk-Dunes16.jpg Dansk-Woods-1.jpg
ct-2-p1600.jpg Dansk-Dunes17.jpg earth_lights_lrg.jpg
Dansk-Beach1.jpg Dansk-Dunes18.jpg HanseSail-AlterStrom2.jpg
Dansk-Beach2.jpg Dansk-Dunes2.jpg HanseSail-AlterStrom.jpg
Dansk-Beach3.jpg Dansk-Dunes3.jpg HanseSail-Mast.jpg
Dansk-Beach4.jpg Dansk-Dunes4.jpg HanseSail-Warnemuende.jpg
Dansk-Beach5.jpg Dansk-Dunes5.jpg LinuxInside_p1600.jpg
Dansk-Beachstones.jpg Dansk-Dunes6.jpg prerow.jpg
Dansk-Cliffs.jpg Dansk-Dunes7.jpg sgi-1440.jpg
Dansk-Dunes10.jpg Dansk-Dunes8.jpg sgi.jpg
Dansk-Dunes11.jpg Dansk-Dunes9.jpg Sonnenuntergang-2.jpg
Dansk-Dunes12.jpg Dansk-Dunes.jpg Sonnenuntergang.jpg
Dansk-Dunes13.jpg Dansk-Nature-1.jpg
muaddib:/home/ij# umount /mnt
[/code]

After umounting the real challenge arise: creation of a RAID5 label! Normally this is no issue, but I guess you like your data and think twice before proceeding... but hey! You have a backup anyway, don't you?!

[code]
muaddib:/home/ij# mdadm --create /dev/md5 --level=5 --raid-devices=2 /dev/vg/r[12]
mdadm: /dev/vg/r1 appears to be part of a raid array:
level=raid1 devices=2 ctime=Mon Mar 2 18:18:09 2009
mdadm: /dev/vg/r2 appears to be part of a raid array:
level=raid1 devices=2 ctime=Mon Mar 2 18:18:09 2009
Continue creating array? yes
mdadm: array /dev/md5 started.
muaddib:/home/ij# cat /proc/mdstat
md5 : active (auto-read-only) raid5 dm-12[2](S) dm-11[0]
1048512 blocks level 5, 64k chunk, algorithm 2 [2/1] [U_]
muaddib:/home/ij# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md5 : active raid5 dm-12[2] dm-11[0]
1048512 blocks level 5, 64k chunk, algorithm 2 [2/1] [U_]
[>....................] recovery = 3.1% (33152/1048512) finish=0.5min speed=33152K/sec
[/code]

After stopping /dev/md5 the new RAID5 label can be written. The data ought to be safe because of the RAID5 algorithm when running with 2 disks. To verify the theory you can mount /dev/md5 again. The next steps can be done with the array online.

muaddib:/home/ij# mount /dev/md5 /mnt
muaddib:/home/ij# dir /mnt/
amigager_back1.jpg Dansk-Dunes14.jpg Dansk-Nature-2.jpg
CapeCod_085.jpg Dansk-Dunes15.jpg Dansk-Priel.jpg
ct-1-p1600.jpg Dansk-Dunes16.jpg Dansk-Woods-1.jpg
ct-2-p1600.jpg Dansk-Dunes17.jpg earth_lights_lrg.jpg
Dansk-Beach1.jpg Dansk-Dunes18.jpg HanseSail-AlterStrom2.jpg
Dansk-Beach2.jpg Dansk-Dunes2.jpg HanseSail-AlterStrom.jpg
Dansk-Beach3.jpg Dansk-Dunes3.jpg HanseSail-Mast.jpg
Dansk-Beach4.jpg Dansk-Dunes4.jpg HanseSail-Warnemuende.jpg
Dansk-Beach5.jpg Dansk-Dunes5.jpg LinuxInside_p1600.jpg
Dansk-Beachstones.jpg Dansk-Dunes6.jpg prerow.jpg
Dansk-Cliffs.jpg Dansk-Dunes7.jpg sgi-1440.jpg
Dansk-Dunes10.jpg Dansk-Dunes8.jpg sgi.jpg
Dansk-Dunes11.jpg Dansk-Dunes9.jpg Sonnenuntergang-2.jpg
Dansk-Dunes12.jpg Dansk-Dunes.jpg Sonnenuntergang.jpg
Dansk-Dunes13.jpg Dansk-Nature-1.jpg

The next step is to add the third "disk":

[code]
muaddib:/home/ij# mdadm --add /dev/md5 /dev/vg/r3
mdadm: added /dev/vg/r3
muaddib:/home/ij# cat /proc/mdstat
md5 : active raid5 dm-13[2](S) dm-12[1] dm-11[0]
1048512 blocks level 5, 64k chunk, algorithm 2 [2/2] [UU]
[/code]

That was the first step. As you can see the third "disk" has been added as a spare device. Because we don't want a spare but a RAID5 we need to expand the number of disks to 3 and tell the RAID to grow its capacity:

[code]
muaddib:/home/ij# mdadm --grow /dev/md5 --raid-devices=3
mdadm: Need to backup 128K of critical section..
mdadm: ... critical section passed.
muaddib:/home/ij# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md5 : active raid5 dm-13[2] dm-12[1] dm-11[0]
1048512 blocks super 0.91 level 5, 64k chunk, algorithm 2 [3/3] [UUU]
[>....................] reshape = 3.1% (33472/1048512) finish=3.0min speed=5578K/sec
[/code]

The last two commands were made with the mounted filesystem that just needs to get enlarged. With XFS you make this happen by invoking xfs_growfs:

[code]
muaddib:/home/ij# df -h /mnt
Filesystem Size Used Avail Use% Mounted on
/dev/md5 1020M 21M 1000M 2% /mnt
muaddib:/home/ij# xfs_growfs /mnt
meta-data=/dev/md5 isize=256 agcount=4, agsize=65532 blks
= sectsz=512 attr=2
data = bsize=4096 blocks=262128, imaxpct=25
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0
log =internal bsize=4096 blocks=1200, version=2
= sectsz=512 sunit=0 blks, lazy-count=0
realtime =none extsz=4096 blocks=0, rtextents=0
data blocks changed from 262128 to 524256
muaddib:/home/ij# df -h /mnt
Filesystem Size Used Avail Use% Mounted on
/dev/md5 2.0G 21M 2.0G 1% /mnt
[/code]

Done!

If you have an LVM on your RAID you'll need to use the appropriate LVM tools to enlarge the PVs and VGs as well. But the hardest work is already done. The reshaping can take a lot of time, as you can see here:

md4 : active raid5 sda6[0] sdc6[2] sdb6[1]
969161152 blocks super 0.91 level 5, 64k chunk, algorithm 2 [3/3] [UUU]
[>....................] reshape = 2.8% (27990592/969161152) finish=1485.0min speed=10562K/sec

There might be other pitfalls if you change your setup from 2-disk arrays to 3-disk arrays. For example you'll need to adopt the changes to your configuration files like /etc/mdadm/mdadm.conf. But this has not much to do with the migration from RAID1 to RAID5 itself.

Many thanks to Goswin Brederlow for his advice and writing a wishlist bug: #517731

Kategorie: 
 

Add new comment

Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer