resizing logical volume and ext filesystem – by example: resize one filesystem and grow another
HOW TO RESIZE VOLUME GROUPS
WHAT I WILL DO:
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:
HOW I WILL DO IT:
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?
WHAT ARE THE LAYERS:
So for shrinking we go from the bottom up.
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).
Turn off the system
THE SHRINK OF /dev/kalikos/home
e2fsck -v -fn -C0 /dev/kalikos/home
– 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
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:
Confirm nothing got damaged with the resize:
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
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)
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:
lvextend -l+18235 /dev/kalikos/root
resize2fs -f /dev/kalikos/root
e2fsck -v -fn -C0 /dev/kalikos/root
Close out the vgs
shutdown -h now
SIDE NOTE ABOUT EXT LIMITATIONS
And dont forget to double check it mounted as swap:
After your done resizing and checking the filesystem:
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.
Here is another link: