Linux Operating Systems

LVM fun: Swap out disk in LVM2 stripe

I’ve been planning to upgrade my LVM2 2 disk striped setup with a new disk for a while. I am currently on the testing phase but I think I have a good way to do it without losing any data.

I plan to implement this on my Odroid XU4 based Cloudshell 2 which is running Ubuntu 16.0.4.

I used this guide as inspiration: LVM fun

I recommend reading that guide first if you are not familiar with LVM.

Phase 1: Testing with loop devices

The plan is as follows:

  • Connect new spare disk via the second USB3.0 port using an external enclosure(the cloudshell only supports 2 SATA drives and both ports are occupied right now)
  • Create a PV(physical volume) on the new disk
  • Add new PV to existing VG(volume group)
  • unmount all VG volumes and/or freeze allocation on the PV to migrate
  • pvmove one of the 2 existing PVs onto this new PV
  • Leave it overnight since it is going to copy sector by sector a 2 TB disk
  • Reduce VG by removing old PV(the one moved at the previous step)
  • Shutdown and swap out old disk with new one
  • Boot and check that the LVs(logical volumes) are correctly mapped to the PVs

OK, here is how I tested.

First, create 3 loopback devices backed by 3 empty files.

Now, create PVs on all these devices

Add the first 2 volumes to a VG:

Check stuff with:

Create 2 striped volumes as such:

The first one will have 1Gb and it will be 50/50 split across the 2 PVs.

The second one will fill up the existing space and also be split between the 2 PVs(size will be around 2.9Gb).

OK, so this is the initial setup, we have 2 disks with 2 logical volumes spread among them using striping.

Format the “disks” and write some files to them for testing( I used mkfs.ext4 on the virtual devices to create filesystems). When done, unmount them and let’s migrate the data.

Migrating the data to disk 3 from disk 2:

In the real world this is the step that takes forever. I noticed that if  interrupted there is a good chance that the process can be resumed. So power outages might not result in data loss.

Resize PV to fill space on /dev/loop2(it has a size of 2GB)

Bonus round: create an unequal stripe by using the extra space at the end of /dev/loop2(perfomance loss, auch…)

You will end up with this setup:


Now, we are going to throw away /dev/loop1.

In the real world this would be: unmap the PV and pull the physical disk, this is where you edit your fstab so the OS does not try to mount automatically(for now) and reboot.

We are now going to simulate a device name reallocation:

If you run pvs, vgs and lvs your volumes should be intact!

Now mount the volumes and check that your test files are still there.

In theory, this is the process but I have yet to try it on real data.


Leave a Reply

Your email address will not be published. Required fields are marked *