==== LVM advanced examples ====
LVM, like many other enterprise class technologies, brings new flexibility to the linux desktop.
While the previous walk-thru is small in scope, the real power of LVM is dealing with a large volume group, and being able to manage the Physical Volumes, Logical Volumes, and maintain your data.
=== LVM Growth ===
Suppose that over the next year, the storage system fills up and needs to be expanded. Initially, you can begin allocating the unallocated space.
In our previous example, we had a 59GB Volume Group (VG) and only 20GB allocated to /var/media - we can grow this out..
For instance, to increase the amount of space available for media files from 20GB to 25GB, run a command such as:
umount /dev/fileserver/media
lvextend -L25G /dev/fileserver/media
mount /dev/fileserver/media /var/media
xfs_growfs /dev/fileserver/media
Note that we're not increasing the size of /var/media, but the actual LVM logical volume that it's mounted from the Operating System, so the OS sees it, and uses it.
//Note - there is a -D switch on xfs_growfs, setting the limit in blocks (not bytes), if it is not set, then xfs_growfs will expand the filesystem to the limit of the volume.//
//**WARNING - one should __never__ reduce the size of an LVM Logical Volume, and xfs, while it can extend a partition/volume, it cannot shrink - to reduce the size of any partition on any filesystem, it's always a backup, and restore to the new volume size**//
=== Growth via MDADM - RAID ===
Leveling up - this is pretty complicated, but a structured approach works - takes time, and of course, always have a backup of your data...
//**WARNING - we're now mucking about deep inside the LVM stack - things might go wrong, may go wrong - so always, I repeat, always have a backup before doing operations like this**//
Let's say we have an LVM Logical Volume Group running on top of a RAID
As an example - we have 4 1TB drives running, and we want to swap them out for 4 4TB drives - we can do this. But it will take a bit of time to migrate and grow, as we do one disk at a time, and let MDADM sync the drives before going to the next disk in the arrary
Note - as a RAID5, 4*1TB = 3TB as we lose the 1TB for parity
Here's the lineup for the example - /dev/md0 is a member of the fileserver volume group (VG)
The RAID5 device is /dev/md0
The members of /dev/md0
/dev/sdb1
/dev/sdc1
/dev/sdd1
/dev/sde1
We first unmount the logical volumes across the entire LVM set.
umount /dev/fileserver/share
umount /dev/fileserver/media
With RAID5, the migration is straightforward, as we use RAID5's ability to run in degraded mode if we have a failed drive
Use mdadm to mark one single drive of the RAID5 mirrors as failed, and then remove it:
mdadm --manage /dev/md0 --fail /dev/sda1
mdadm --manage /dev/md0 --remove /dev/sda1
Pull out the sda hard drive and replace it with the new 4TB drive.
Go into fdisk, and partition the drive (see above) making sure to split the physical drive into two partitions, sda1 as the same size as the old 1TB sda1, and add new sda2 partion, which we add the remaining balance of sda to sda2 (approx 2.8TB)
Now we manage sda1 back to /dev/md0 - remember, that we marked sda1 as failed
mdadm --manage /dev/md0 --add /dev/sda1
MDADM will then add /sda1 back to the array and start rebuilding the RAID5 set - once it's done, do the same with /sdb1 and so forth...
In the end of all this, we have 8 sets of partitions the sd<d,c,d,e>1 set, and the remainders - so we take the second set of partitions, and build that into a new /dev/md1 device
mdadm --create --verbose /dev/md1 --level=5 --raid-devices=4 /dev/sdb2 /dev/sdc2 /dev/sdd2 /dev/sde2
So now we have a second MD RAID5 set - and this one is 12TB (remember that md0 is already 4TB recreated from the previous 4 1TB drives)
Let md1 finish it's sync up - can check mdstat to see the progress - when it's done...
we add them to the Physical Volume group (pv)
pvcreate /dev/md1
and extend the volume group
vgextend fileserver /dev/md1
Now the fileserver Volume Group has 12TB of storage compared to the previous 3TB of storage, and we can use LV to grow the file systems...
The previous allocations were 750GB for /share and 2TB for media, and now we want to put 3TB for /share, and 7TB /media (remember, we don't allocate the entire VG space to keep a bit in reserve)
lvextend -L7T /dev/fileserver/media
lvextend -L3T /dev/fileserver/share
And now we have 10TB of space - and we can grow the file systems according - and this is why xfs is much better than ext4
Mount the file systems again - as they were unmounted before we started swapping out disks...
mount /dev/fileserver/media /var/media
mount /dev/fileserver/share /var/share
Now we tell xfs to grow... but the filesystem must be mounted before we do this...
xfs_growfs /dev/fileserver/media
xfx_growfs /dev/fileserver/share
And xfs will grow the filesystem to the extent of the volume.
What I'm getting at is that with LVM, we can definitely swizzle things around with Physical Volume, and Logical Volume all within the same Volume Group set - it's a very powerful solution, and one that enterprises use all the time.
Always do your homework, have a plan, and do some research - this is Linux after all, and changes happen and API's evolve - and always have a backup plan.
