Disks, Partitions, Filesystems, Inodes, LVM & RAID

In one line

How a raw disk becomes a usable directory: devices and partitions, filesystems and mounting (including /etc/fstab), why a disk can be 'full' with free space left (inodes), resizing with LVM, and surviving disk failures with RAID.

0/5 · 0%

Think of it like this

A DISK is an empty plot of land; PARTITIONS divide it into lots; a FILESYSTEM is the building and its filing system on a lot; MOUNTING attaches that building to a street address in your directory tree (/var/lib/postgresql). LVM lets you merge and resize lots later; RAID keeps copies so one collapsed building doesn't lose everything.

Key ideas

01
DEVICES: disks appear under /dev: sda, sdb (SATA/SCSI), nvme0n1 (NVMe, including AWS EBS on Nitro instances), xvda (older Xen). lsblk shows the tree of disks, partitions, and mount points; blkid shows each partition's filesystem type and UUID.
02
PARTITIONS: fdisk (MBR/GPT) or parted/gdisk (GPT) create them; GPT is the modern default. Many cloud data volumes skip partitioning and put the filesystem on the whole device.
03
FILESYSTEMS: mkfs.ext4 or mkfs.xfs create one (XFS is the RHEL/Amazon Linux default and good for large files; ext4 is the Ubuntu default). mount /dev/nvme1n1 /data attaches it; umount /data detaches it (fails with 'target is busy' if a process has files open: lsof +D /data finds it). Make mounts permanent in /etc/fstab using the UUID (device names can change between boots) and the nofail option for non-root volumes, so a missing volume doesn't block booting. Always test with mount -a before rebooting.
04
INODES: every file and directory uses one inode (the record of its owner, permissions, size, and where its data blocks are; the name lives in the directory, not the inode). A filesystem has a fixed number of inodes, so millions of tiny files (session files, cache entries, mail queues) can exhaust them while df -h still shows free space: writes fail with 'No space left on device'. df -i shows inode usage.
05
LVM (Logical Volume Manager) adds a flexible layer: PHYSICAL VOLUMES (disks/partitions, pvcreate) are pooled into a VOLUME GROUP (vgcreate), from which you carve LOGICAL VOLUMES (lvcreate) that hold filesystems. You can add a disk to the group and grow a volume online (lvextend -r -L +50G, where -r also resizes the filesystem) and take snapshots. In the cloud you'd more often just grow the EBS volume and run growpart + resize2fs/xfs_growfs.
06
RAID combines disks for redundancy and/or speed: RAID 0 (striping: fast, NO redundancy, one disk loss = all data lost), RAID 1 (mirroring: survives one disk loss, half the capacity), RAID 5 (striping + parity: survives one disk, slow rebuilds), RAID 6 (two parity disks), RAID 10 (mirrored stripes: fast and redundant, the usual choice for databases on physical servers). Software RAID uses mdadm; cat /proc/mdstat shows array health. RAID is NOT a backup: deleted or corrupted data is deleted on every disk (Stateful Systems course, backups). EBS already replicates within an AZ, so RAID on cloud volumes is mostly for combining throughput.

Code & diagrams

add and mount a new data diskbash

lsblk                                        # find the new, empty device, e.g. nvme1n1
sudo mkfs.xfs /dev/nvme1n1
sudo mkdir -p /data
sudo blkid /dev/nvme1n1                      # UUID="3f1c..." TYPE="xfs"
echo 'UUID=3f1c... /data xfs defaults,nofail 0 2' | sudo tee -a /etc/fstab
sudo mount -a && df -h /data                 # test fstab BEFORE rebooting

disk 'full' but df says free space: check inodesbash

$ df -h /var | tail -1
/dev/nvme0n1p1   30G   12G   18G  40% /
$ df -i /var | tail -1
/dev/nvme0n1p1  1966080 1966080     0  100% /
$ sudo find /var -xdev -type f | cut -d/ -f2-4 | sort | uniq -c | sort -rn | head -3
 1843022 var/lib/php
   61201 var/cache/apt

LVM: pool two disks and grow a volume onlinebash

sudo pvcreate /dev/nvme1n1 /dev/nvme2n1
sudo vgcreate data_vg /dev/nvme1n1 /dev/nvme2n1
sudo lvcreate -n pg_lv -L 150G data_vg && sudo mkfs.xfs /dev/data_vg/pg_lv
# later, when it fills up:
sudo lvextend -r -L +40G /dev/data_vg/pg_lv   # grows the LV and the filesystem, no downtime
sudo vgs; sudo lvs

the storage stackdiagram

Rendering diagram…

Explain it without notes

How can a filesystem report 'No space left on device' while df -h shows 60% free?

Why reference filesystems by UUID in /etc/fstab?

Why isn't RAID 1 a backup?

Practice

Your 100 GB EBS data volume (xfs on /data, no LVM) is 95% full. Grow it to 200 GB without downtime.

Trade-offs

↔
LVM adds flexibility (pooling, online growth, snapshots) at the cost of another layer to understand; on cloud VMs, resizing the volume directly is often simpler. RAID 10 trades half the capacity for speed and resilience; RAID 5/6 save capacity but rebuild slowly and suffer under write-heavy workloads.

Done when you can

I can create a filesystem, mount it, and make the mount survive reboots with a UUID in fstab
I check df -i as well as df -h when a disk reports full
I can grow a volume online with LVM or growpart + xfs_growfs
I know which RAID levels survive a disk failure, and that RAID isn't a backup