Linux Storage Fundamentals

The Storage Stack, Top to Bottom

flowchart TB FS["Filesystem: ext4 / xfs"] --> LV["Logical Volume (LVM)"] LV --> VG["Volume Group"] VG --> PV["Physical Volume"] PV --> PART["Partition"] PART --> DISK["Physical/Virtual Disk (/dev/sda, /dev/nvme0n1)"]

A filesystem sits on top of a partition (or an LVM logical volume, which itself sits on partitions) — understanding this stack is essential for correctly resizing storage on a running server.

Disks & Partitions

lsblk                       # tree view of all block devices and their mount points
lsblk -f                     # + filesystem type and UUID
sudo fdisk -l                 # list disks and partition tables
sudo parted /dev/sdb print    # partition table for a specific disk

sudo fdisk /dev/sdb            # interactive partitioning (MBR/legacy-friendly)
sudo parted /dev/sdb            # interactive partitioning (GPT-friendly, scriptable)

Formatting & Mounting

sudo mkfs.ext4 /dev/sdb1        # format a partition as ext4
sudo mkfs.xfs /dev/sdb1          # format as xfs

sudo mkdir /mnt/data
sudo mount /dev/sdb1 /mnt/data
df -hT                            # confirm mount + see usage + filesystem type

LVM: Logical Volume Management

LVM adds a flexible layer between raw partitions and filesystems, letting you resize storage without unmounting or being constrained by physical disk boundaries.

flowchart LR D1["/dev/sdb"] --> PV1[Physical Volume] D2["/dev/sdc"] --> PV2[Physical Volume] PV1 --> VG[Volume Group: vg_data] PV2 --> VG VG --> LV1["Logical Volume: lv_app (50GB)"] VG --> LV2["Logical Volume: lv_logs (20GB)"]

sudo pvcreate /dev/sdb1                    # mark a partition as a Physical Volume
sudo vgcreate vg_data /dev/sdb1             # group PVs into a Volume Group
sudo lvcreate -L 50G -n lv_app vg_data       # carve out a Logical Volume
sudo mkfs.ext4 /dev/vg_data/lv_app
sudo mount /dev/vg_data/lv_app /app

# Growing an LV + filesystem live (no downtime)
sudo lvextend -L +10G /dev/vg_data/lv_app
sudo resize2fs /dev/vg_data/lv_app          # ext4
sudo xfs_growfs /app                          # xfs (mounted filesystem, not device)

RAID Basics (Software: mdadm)

Level	Description	Fault Tolerance
RAID 0	Striping — speed, no redundancy	None (any disk failure = total loss)
RAID 1	Mirroring — full duplicate	Survives 1 disk failure
RAID 5	Striping + distributed parity	Survives 1 disk failure
RAID 10	Mirrored stripes	Survives multiple failures (depending on layout)

cat /proc/mdstat                       # current RAID array status
sudo mdadm --detail /dev/md0

Swap: Virtual Memory Overflow

free -h                     # RAM + swap usage
swapon --show                 # active swap devices

sudo fallocate -l 4G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

vm.swappiness (0–100, /proc/sys/vm/swappiness) controls how aggressively the kernel swaps out idle memory versus reclaiming page cache — lower values keep more in RAM, generally preferred on database/latency-sensitive servers.

Production Considerations

Never xfs_growfs a device — it operates on the mounted filesystem path; ext4’s resize2fs works on the device or the mount point.
Monitor disk usage with alerting well before 100% — a full root filesystem can prevent even login/logging from working.
High swap usage on a server usually signals memory pressure, not a free lunch — sustained swapping badly degrades latency-sensitive workloads (databases especially).

Quick Interview Answer

“The storage stack goes disk → partition → (optionally LVM physical volume → volume group → logical volume) → filesystem. LVM lets you resize storage live by growing logical volumes across pooled physical volumes, then growing the filesystem on top with resize2fs (ext4) or xfs_growfs (xfs, on the mount point). RAID adds redundancy or performance at the block level — RAID 1 mirrors, RAID 5 stripes with parity.”

Common Mistakes

Running xfs_growfs against /dev/sdb1 instead of its mount point — xfs tools operate on the mounted path.
Treating RAID as a backup strategy — RAID protects against disk failure, not accidental deletion, corruption, or ransomware.
Not monitoring swap usage and being surprised by sudden latency spikes under memory pressure.