Managing Storage with LVM and Partitions

Let us start with the basics. A hard drive (like a 500GB SSD) is a physical disk. On that disk, you create partitions. A partition is a contiguous section of the disk. For decades, partitions were fixed: you create a 50GB partition for the operating system, a 200GB partition for data, etc. If you ran out of space in the data partition, you had to repartition the whole disk, which meant backing everything up, deleting the partition, creating a new bigger one, and restoring the data. This is painful.

LVM stands for Logical Volume Manager. It is a software layer that decouples the physical storage from the logical storage. Think of it this way: instead of cutting a pizza (the disk) into slices (partitions) that cannot be unsliced, LVM lets you pour ingredients (physical blocks) into a big bowl (volume group) and then ladle out portions (logical volumes) that can be changed anytime.

Here are the three key LVM components you need to remember for EX200:

Why does LVM exist? It solves three big problems:

The old way (without LVM) is called MBR partitions or GPT partitions. MBR stands for Master Boot Record, an old standard limited to 2TB disks and four primary partitions. GPT stands for GUID Partition Table, a newer standard that supports disks larger than 2TB and up to 128 partitions. Even GPT partitions are fixed in size once created.

Here is how you set up LVM step-by-step:

First, you prepare the disk. If it is a new disk (say /dev/sdc), you can create a partition covering the whole disk using fdisk or gdisk. Or you can use the whole disk as a PV without partitioning (called "whole-disk PV"). EX200 often tests the whole-disk PV approach because it is simpler.

Second, create the PV: pvcreate /dev/sdc. This adds LVM metadata to the disk headers.

Third, create the VG: vgcreate vg_name /dev/sdc. You can add more PVs later with vgextend.

Fourth, create the LV: lvcreate -L 10G -n lv_name vg_name. The -L flag sets the size, -n sets the name.

Fifth, format the LV with a filesystem: mkfs.ext4 /dev/vg_name/lv_name.

Sixth, mount it: mount /dev/vg_name/lv_name /mount_point.

To make the mount permanent, add an entry to /etc/fstab.

When you need more space, you extend the LV with lvextend -L +5G /dev/vg_name/lv_name. Then you resize the filesystem with resize2fs (for ext4) or xfs_growfs (for XFS). Without LVM, you would have to move data, delete the partition, recreate it, and restore. This is why IT professionals love LVM.

Deleting is the reverse: unmount, delete LV with lvremove, remove VG with vgremove, and remove PV with pvremove.

EX200 will also test thin provisioning, where you can create an LV that appears larger than the available physical space but only consumes space as data is written. This is like a hotel that has 50 rooms but sells 100 room reservations, betting not everyone shows up.

Finally, a key detail: the logical volume device path is /dev/vg_name/lv_name. The exam uses this path constantly.

Now you know what LVM replaces: it replaces rigid, painful partition resizing with flexible, online storage management. Memorise the three tiers: PV -> VG -> LV. That is the exam's favourite structure.

Imagine you work as a junior sysadmin for a company called "DataFlow Ltd". They have two 1TB physical disks in a server running a database. The database is growing at 20GB per month. Six months ago, you carved out a 200GB partition for the database logs. Last week, the logs filled up and the database crashed. The on-call engineer had to restore from a backup, losing four hours of transactions. The boss is furious.

You decide to implement LVM to prevent this happening again. Here is exactly what you do:

First, you back up the existing data. Always. Then you repartition both disks so each has one big partition using LVM flag (type 8e in fdisk). You create a volume group called vg_database. You add both disks: vgextend vg_database /dev/sda1 and vgextend vg_database /dev/sdb1. Now your pool is 2TB.

Second, you create two logical volumes: lv_data of 1.2TB for the actual database files, and lv_logs of 400GB for the logs. You format each with mkfs.xfs because the developers prefer XFS. You mount them to /var/lib/mysql and /var/log/mysql respectively.

Third, you add entries to /etc/fstab so they mount automatically on reboot. You test by rebooting the server.

Six months later, the logs are growing faster than expected. They are at 380GB out of 400GB. You decide to extend lv_logs by 200GB. You run:

lvextend -L +200G /dev/vg_database/lv_logs xfs_growfs /mount/logs

No reboot, no downtime, no backup restore. The database keeps running. The boss is happy.

In another scenario, a development team needs a temporary 50GB volume for testing. You create a thin pool and a thin logical volume: lvcreate -T vg_database/thin_pool -L 100G then lvcreate -V 50G -n lv_test -T vg_database/thin_pool. The volume only uses as much disk as the test data actually occupies. When the testing finishes, you delete the thin LV and the thin pool. The space returns to the volume group.

Real IT professionals also use LVM for: - Snapshots: Before patching a production system, take a snapshot of the root volume. If the patch breaks something, roll back in seconds. - Migration: Move data between disks without downtime. Add a new PV, move data from old PV with pvmove, remove old PV. - Disaster recovery: Back up the LVM metadata with vgcfgbackup. If disaster strikes, restore metadata instantly.

The bottom line: LVM turns storage from a fixed resource into a flexible, on-demand pool. For a junior sysadmin on EX200, knowing how to create, extend, and remove LVM volumes is the difference between passing and failing the lab.