HOW TO RESIZE VOLUME GROUPS
###########################

GOOD LINKS:
http://blog.shadypixel.com/how-to-shrink-an-lvm-volume-safely/
http://www.tldp.org/HOWTO/LVM-HOWTO/extendlv.html
http://www.techrepublic.com/blog/linux-and-open-source/how-to-use-logical-volume-manager-lvm-to-grow-etx4-file-systems-online/

WHAT I WILL DO:
I will show the example of shrinking and expanding.

WHY:
I was given a system which had a really small
/ root partition that filled up to 100% and was causing errors obviously. The root partitions was a logical volume /dev/kalikos/root

The system had an overly dramatic (huge) home volume /dev/kalikos/home, and a normal sized swap /dev/kalikos/swap.

WHAT I WILL DO IN PARTICULAR:
I will shrink my home volume (filesystem first, then logical volume associated with the filesystem) then I will grow my root volume so that its a reasonable size (I will grow the logical volume first and then the volume group)

HOW I WILL DO IT:
From a boot cd – I will use KNOPPIX as they have everything I need.

MORE INFO:
Yes this is a kalilinux box.

So I couldnt really do much from within the system and I didnt have the kali linux boot usb anymore.

So I made a KNOPPIX 7.2 boot cd (on another computer but thats an unimportant detail)

WHY IS THE ORDER FOR SHRINKING AND GROWING THAT WAY?
So for shrinking a volume with a filesystem and lvm, one must do this:
1. shrink filesystem (in between steps make sure filesystem didnt get messed up)
2. shrink logical volume
But why? Well because you have to follow the layers of the system, everything in the computer world works with layers, and yes 1s and 0s too, but more importantly layers. The storage layers for me are like this (and these are the layers that everyone gets when they install any linux that lets you put LVM on it – this is considering you didnt do an encrypted volume)

WHAT ARE THE LAYERS:
Drives
Partitions
Logical Volume
Filesystem
Mounting
Useage

So for shrinking we go from the bottom up.
Literally Filesystem is at the bottom and we go up to logical volume.

For expanding we go from Logical volume and go down to filesystem.

Notice how in there is the word mounting… that means that before we shrink and expand we should probably unmount everything – now some filesystems have special software (covered in some of these links I am about to show you) that can help you resize online (meaning resize filesystem while its being used) – Note that what really bothers a mounted filesystem is not the logical volume changing underneath it but the filesystem changing underneath it, and of course you will receive errors/trouble if you shrink or expand a logical volume while online and that shrink/expansion messes with the filesystem – usually that is a worry with shrinks of the logical volume, if you shrink the logical volume under the filesystem size you just broke some laws of physics and should stop what your doing and rethink life under a tree.

Anyhow the best way to do all of this is with everything unmounted, but wait your filesystem needs to be up for you to use the software to shrink and resize… ahh circular problems. I love those, what the solution to these types of problems? The solution is always to bring in another entity to take over so the problem doesnt happen. the solution is to bring in another system one that can handle the resizing of filesystems and logical volumes.  So you bringin in KNOPPIX 7.2

So google for them and download and make a bootable CD or USB. If your making your bootable USB from a windows OS its really easy to just get the pendrive software and point it at the USB drive and the downloaded ISO file. Otherwise you can manually do it from Windows or Linux using partitions (dont forget to make a bootable fat32 partition) and also apply syslinux to it as a bootloader. There are alternatives that you can setup – easier to set em up from linux as these are all natively linux software – an alternative like grub. Anyhow I wont get into any of this, for now download knoppix on your windows pc and burn it with a pendrive (its a software you can google for, the software i used is called Yumi).

Enough Talk!!!

START
#####

BOOT
=====

Turn off the system
Boot into KNOPPIX or similary SystemRescueCD
And open up a terminal window

THE SHRINK OF /dev/kalikos/home
=================================

lvscan
– see that it detects your logical volumes as inactive

vgchange -ay
– that activates them all

e2fsck -v -fn -C0 /dev/kalikos/home
– the C0 and v are optional, C0 gives you a progress bar and v gives you end of operation stats (look at the blocks free percentage that will change soon)

– Figure out the new size you want, lets say I want to shrink by 30GB. My original size was 184, the new size is thehttp://www.tldp.org/HOWTO/LVM-HOWTO/extendlv.htmln 154GB (this is the new value). Well for the filesystem resize take 90% of that size (154 B * .9 = 138 GB) and shrink to that instead (we will then shrink the volume to the 100% value which is 154)

resize2fs /dev/kalikos/home 138G
– if this says first run e2fsck with -f, ignore that just run this instead “resize2fs -f /dev/kalikos/home 138G” – so just add -f to the resize2fs command

lvreduce -L 154G /dev/kalikos/home

– Why are we shrinking the filesystem below what we want? Well simple really the documentation for resize2fs doesnt talk about if the gigabytes they use, the “G”, if its the standard computer gigabytes (1024^3 bytes) [I personally refer to these as base 2 GB, but more accurately known as gibibytes – dont get me wrong this is the more accurate term that shouldnt of been invented and thus noone uses it] or if its the drive manufacturer gigabytes (1000^3 byte) [Or to what I refer to as base 10 GB]. Anyhow so we compinsate for that difference by making the filesystem 10% smaller (as the difference between 1000^3 and 1024^3 is a little less then 10%) by finding out its 90% value (so for us we wanted 154 G and 90% of that is 138G)… Anyhow dont worry we fill up the extra remaining free space thats not being used like this:

resize2fs /dev/kalikos/home
– if this says first run e2fsck with -f, ignore that just run this instead “resize2fs -f /dev/kalikos/home” – so just add -f to the resize2fs command
– Again we did this to recapture that free space we might be losing out on because we only used 90% of our target value as described above

Confirm nothing got damaged with the resize:
e2fsck -v -fn -C0 /dev/kalikos/home

DISCUSSION OF lvextend BEFORE THE EXPANSION
=============================================

Before we do it I must discuss the 2 different options in lvextend that are going to be used to extend the volume.

lvextend -L[+,-, ] SPACE /dev/volgroup/logicalvol
lvextend -l[+,-, ] EXTENTS /dev/volgroup/logicalvol

Of course for the above command you will not write out the square brackets [] or the commas and you will put in numbers in place of EXTENTS represting the extents and in place of SPACE you will put in human readable form sizes – you can look up the proper letters for MB, GB and TB in the man page of lvextend, but I know for a fact its G for GB, so then I assume for MB its M and for TB its T.

The top method with -L is if you want to specify the SPACE with like 100G or 100M or whatever, and the -l is if you want to specify the expansion more accurately with “extents” – extents to logical volume is what an LBA is to a disk or a block is to a filesystem, it is its unit of identification and unit of increment, every volumegroup is divided up into extents and each extent is like 64 MB (some number that can be set to different sizes, but its a big number) so 2 extents would be 128 MB in this example of this sentence. So -l is to allow to expand using the extent unit.

The +,- or no plus minus (I wrote as a space)

Side note:
The -L will adjust each expansion or resize to an integer number of the -l. For example lets say your extents are all sized 64 MB in your logical volume systems, and you decide to make a new logical volume of size 110 MB, well the final size will actually be 64MB, because it can only go in increments of 64… It could technically go to 128 but when making something new linux always likes to be on the conservative side as I understand.

THE EXPANSION OF /dev/kalikos/root
===================================

So the order is first expand the logical volume and then the filesystem.

But before any of this expansion stuff lets see how much free space we have available. To do this look at the volume group stats.

Before expansion ensure your fs is healthy:
e2fsck -v -fn -C0 /dev/kalikos/root
– Take a note of the used block size %, in my case it was like 95% used

vgdisplay
– That will show you free extents, lets pretend its 18235 (and each extent being a certain trivial number – trivial because we just want to expand all the way out to the available free space)

lvextend -l+18235 /dev/kalikos/root
– This will extend the root filesystem into the final free space that I wanted.

resize2fs -f /dev/kalikos/root
– I just put in the -f so it doesnt cry about it

e2fsck -v -fn -C0 /dev/kalikos/root
– no mistakes because we were careful
– Take a note of the the block size used, in my case it went down top 14% 🙂 because we gave it more free space

Close out the vgs
vgchange -an

shutdown -h now
– or “shutdown -r now” if you want to reboot just remember to get the bootable USB out before BIOS detects it

SIDE NOTE ABOUT EXT LIMITATIONS
=================================
ext filesystems has known limitations about expanding past certain sizes like 16GB (it simply doesnt support it as its the limitation). Also resize2fs can take on quiet a load during big resizes it might be recommended to mount some extra swap space using the swapon command.. For example I know that my swap space is /dev/kalikos/swap and since we activated the volume group we can use it.
So do this command before the hefty filesystem resize commands “resize2fs”:
swapon /dev/kalikos/swap

And dont forget to double check it mounted as swap:
free -m
cat /proc/swaps
swapon -s

After your done resizing and checking the filesystem:
swapoff /dev/kalikos/swap

ANOTHER NOTE ABOUT EXPANSION
==============================

The is also a case of if your just looking to expand a volume and you had a RAID like mdadm underneath your logical volume. Well then before all those expansion steps you would have to expand the volumegroup by doing pvresize commands. pvresize commands are just ran pointing at the physical volume, like lets say you had an md5 that grew in size, you can do “pvresize /dev/md5” and the volume group would grow to show that new size after wards.
Link:
http://muzso.hu/2009/07/28/how-to-resize-an-lvm-physical-volume-without-a-reboot

Here is another link:
http://www.turnkeylinux.org/blog/extending-lvm
That one shows if you expand the volume group by ADDING another physical volume, the previous link shows if you GROW a phyiscal volume.