Logical Volumes

Motivation

When you setup your system you will partition your hard-drive and reserve some space for it. Later you will find that the space is to small. Especially on server systems it is a good idea to have separate partition so that e.g. an user in his/her home-directory can not fill the space for the / and /var partitions, etc.. But on important server systems you also want to be able to increase that space without rebooting. You might also come across the case that you want to create a consistent snapshot of a partition or you want a volume that stretches over more then one physical device.

For all of this LVM (Logicial Volume Management) has a solution. Usually it is a good idea to setup your system with LVM even if it is just a personal laptop.

LVM concepts and terms

There are 3 main entities in LVM:

1. pv - physcial volume: where you store your data: usually a partition on a hard drive e.g. /dev/sda7 or a complete drive e.g.: /dev/sdg
2. vg - volume group: pv's grouped together to form one pool where you can store your data. Each vg has a name. E.g. you could use rootvg as the name of your main vg.
3. lv - logical volume - a block-device where you can create your files-system. Each lv takes up a space in one vg. E.g. you could have rootlv as the lv for your root file-system. If the name of the volume group would be rootvg then that would be /dev/rootvg/rootlv

Thick vs Thin

1. thick volumes are the default, they reserve all blocks in advance. Initially LVM offered only thick volumes. The main downside here are snapshots which then are computationally expensive: If you have a snapshot on a thick volume it slows down your write speed by a factor of about 3.
2. thin volumes only take up space as data is written to it. Snapshots of thin volumes are cheap and have only little impact on performance.

When to use what? For normal volumes it is a good choice to stick with the thick volumes. If you have a server that hosts a lot of virtual machines that you want to backup and snapshot then thin volumes are a better choice.

Creating a LVM, extending it and creating a snapshot

To create an vg we first not a few pv:

# those partitions below should be unused:
pvcreate /dev/sda7
pvcreate /dev/md5
pvcreate /dev/sdf6
# now they are marked as pv and are being able to be used in LVM.
vgcreate myvg /dev/sda7 /dev/md5
# if we later find there is not enough spaced we can extend the vg:
vgextend myvg /dev/sdf6
# now we are ready to create a logical volume:
lvcreate -L 5G -n testlv myvg
# the above creates a lv named "testlv" in our myvg volume group
# with a size of 5GB

After this we have a device /dev/myvg/testlv or /dev/mapper/myvg-testlv. This can be used as a normal block device. E.g. we can format it with an ext4 filesystem and mount it:

mkfs.ext4 /dev/myvg/testlv 
mkdir /mnt/test
mount /dev/myvg/testlv /mnt/test

If we now find we want to make the testlv bigger we can do this online:

lvextend -L +2G myvg/testlv

While the device is now bigger we also want the file-system to be able to use that additional space. For this we need to resize the file-system. E.g. by:

resize2fs /dev/myvg/testlv 

Let's say we have a database that writes to that volume and we do not want to stop it for too long in order to create a consistent backup. One way to do this would be to create a snapshot. But beware that if it is a thick volume that this will cost you some significant of performance.

lvcreate -L 500M -s -n testsnap myvg/testlv

The above would create a logcial volme testsnap which is a snapshot of testlv. There is 500M space for differences to the original volume. So during the time the snapshot exists you should not write more then 500M to your original volume, otherwise the snapshot becomes invalid. (In a real world example you would reserve more space).

Change horses while riding them

==