Recently I needed to make a copy of a failing 255G Samsung 850PRO SSD that was in a RAID 1 mirror (where the second SSD had already failed) to a new quicker Intel SSD, there were two issues that were critical.
- The new Intel SSD was slightly smaller by 13G so the RAID controller would not just accept it and rebuild the mirror and
- The original Samsung SSD was a single LVM Physical Volume (except for a 2G /boot partition) with no free space.
Assuming you know what LVM is (Logical Volume Manager) on a Linux machine… The Physical Volume (PV) consisted of a single Volume Group (VG) and in the VG was configured with five (5) Logical Volumes (LV). The original OS install automatically used all of the disk leaving no free space.
Step 1 required me to resize each Linux ext4 file system (except for the “/” root file system) to the smallest size possible. Luckily I was able to umount each, run a fschk and resize2fs and then resize the logical volume they each sat in (using lvreduce). This yielded 33G of free space in the Volume Group they all resided in.
# vgs VG #PV #LV #SN Attr VSize VFree vg_os 1 5 0 wz--n- 235.87g 33.43g #
I next rebooted into a GPARTED ISO image thinking I could just do a resize of the PV by 20G but I was not able to get it to display the desktop screen on the Dell R620 despite trying EVERY option and combination of options, so instead I booted an Ubuntu Desktop Live CD as they have GParted installed.
My first attempt to resize the PV smaller resulted in an error message similar to:
/dev/sda2: cannot resize to xxxxx extents as later ones are allocated.
It appears that some extents still remained at the end of the disk despite the PV showing as 33G free at the end. A quick Google found numerous similar experiences but 1 page yielded a perfect solution. From the root prompt run:
pvs -v --segments /dev/your_device_here
to see what extents are currently allocated.
Then use PVMOVE to migrate them from the end of the disk. The beauty is you can use pvmove on a live system, as it makes a mirror of the extent before switching access to the new copy so its very cautious and safe to use. The command looks similar to:
pvmove -i5 --alloc anywhere /dev/device:sssss-eeeee
Where “sssss” is the starting segment and “eeeee” is the ending segment reported in the pvs -v command. The “-i5” just reports evey 5 seconds so you can see it make its way to 100% completed.
Once this is done, reboot the Ubuntu Desktop ISO and use GParted again, I freed up 20G with no issues, to check the partitions, I rebooted my original image and the server came up fine reporting 20G less in the vgs command.
# vgs VG #PV #LV #SN Attr VSize VFree vg_os 1 5 0 wz--n- 214.17g 11.39g #
I then mounted the clonezilla ISO and booted into it, after the Language and Keymap selection, select Disk to Local Disk, select the Source and Destination Disks, select “Device to Device” and using “Expert Mode” to skip checking the target disk size (option icds enabled). Confirm all the prompts to make sure you did select the right disks etc.
Once started, Clonezilla copied the entire SSD to the new smaller one and reported no errors. I then rebooted into the controller card and set the new disk as the boot disk.
Needless to say the new disk booted fine and I can now go to the next step of changing the Intel SSD to RAID 1 and then install another one to begin the mirror process.