LVM, Partitions & Capacity Discipline

Module 4 – Storage Engineering

Disks Are Not Infinite

Infrastructure does not fail because of Kubernetes.

It fails because:

Root partition fills up
Logs grow uncontrollably
Databases consume unexpected space
Volumes cannot be extended
Storage layout was never designed

Storage must be engineered — not accepted as default.

1. Storage Architecture Overview

Modern enterprise Linux systems typically use:

Physical Disk
Partition Table
LVM (Logical Volume Manager)
Filesystem

Stack model:

Physical Disk (/dev/sda)
    ↓
Partition (/dev/sda2)
    ↓
Physical Volume (PV)
    ↓
Volume Group (VG)
    ↓
Logical Volume (LV)
    ↓
Filesystem (ext4/xfs)

If you do not understand this chain, you cannot safely extend storage.

2. Why LVM Matters

Without LVM:

Partition sizes are fixed
Resizing is risky
Scaling requires downtime

With LVM:

Logical volumes can grow
Storage can be added dynamically
Capacity planning becomes flexible

LVM introduces abstraction.

Abstraction enables scalability.

3. Inspecting Your Current Storage

Start by understanding your system.

List block devices:

lsblk

Check filesystem usage:

df -h

Inspect LVM structure:

sudo pvs
sudo vgs
sudo lvs

Do not proceed until you understand:

Which device holds root
Whether LVM is used
How much free space exists

4. Designing a Better Storage Layout

Default layout often places everything on /.

This is acceptable for basic systems.
Not acceptable for engineered labs.

Recommended separation:

/ (root) → System files
/var → Logs & application data
/home → User data
/opt → Custom software (optional)

Why separate /var?

Because logs grow.

If /var fills up and shares root, the entire system crashes.

Segmentation prevents total failure.

5. Creating a New Logical Volume (Lab Simulation)

Add a second virtual disk in VirtualBox.

Then verify:

lsblk

You should see something like /dev/sdb.

Step 1 – Create Physical Volume

sudo pvcreate /dev/sdb

Verify:

sudo pvs

Step 2 – Extend Volume Group

Identify your VG:

sudo vgs

Then extend:

sudo vgextend <your-vg-name> /dev/sdb

Step 3 – Create Logical Volume

Example: Create 5GB volume for /data

sudo lvcreate -L 5G -n data_lv <your-vg-name>

Verify:

sudo lvs

Step 4 – Format Filesystem

sudo mkfs.xfs /dev/<vg-name>/data_lv

(Use xfs or ext4 depending on your system.)

Step 5 – Mount the Volume

Create mount point:

sudo mkdir /data

Mount:

sudo mount /dev/<vg-name>/data_lv /data

Make permanent in /etc/fstab.

6. Extending a Logical Volume

Simulate growth need.

Extend volume by 2GB:

sudo lvextend -L +2G /dev/<vg-name>/data_lv

Resize filesystem:

For XFS:

sudo xfs_growfs /data

For ext4:

sudo resize2fs /dev/<vg-name>/data_lv

Verify:

df -h

No downtime required.

That is the power of LVM.

7. Simulating Disk Pressure

Simulate disk fill:

sudo fallocate -l 2G /data/testfile

Check usage:

df -h

Observe system behavior.

When storage reaches 95%:

Logging slows
Services may fail
Package installs break

Storage discipline prevents production incidents.

8. Swap Considerations

Check swap:

free -h

Swap is not memory.
It is emergency overflow.

Too much swap usage indicates:

Memory misallocation
Application inefficiency
Resource planning failure

Swap must be monitored — not ignored.

9. Capacity Planning Mindset

Ask:

How fast are logs growing?
What writes heavily to disk?
How much free space remains?
What happens at 90% usage?

Infrastructure thinking means anticipating growth.

10. Snapshot Before and After

Before modifying storage:

Take snapshot:
04-before-storage-changes

After successful LVM setup:

Take snapshot:
05-storage-engineered

Version control applies to storage too.

11. Lab Assignment

Add a new virtual disk to your VM.
Convert it to an LVM Physical Volume.
Extend existing Volume Group.
Create a dedicated logical volume.
Mount it permanently.
Extend it once.
Simulate disk pressure.
Document what happens near full capacity.

Deliverable:

Explain:

Why LVM is superior to static partitions.
What risks exist if /var fills up.
How you would monitor disk usage in production.

If you cannot explain growth strategy, you do not control your infrastructure.

12. Production Reflection

Consider:

How does this map to AWS EBS volumes?
How would you scale storage in cloud?
What happens if disk latency increases?
How do databases behave under storage pressure?

Storage is not glamorous.

But it breaks systems silently.

Module Completion Criteria

You are ready for Module 5 when:

You understand PV, VG, LV relationships.
You can extend storage safely.
You can simulate disk pressure.
You engineered storage intentionally.

→ Module 5 – Multi-Node Lab Design