Terminal.Drill Get the app
ch11/l01

Devices, filesystems, and mounts

Separate block devices from filesystems and mount points.

lsblk -f 25 min read, 30 min lab operator

Storage commands are dangerous because names can be similar and device paths can change. `lsblk -f`, `blkid`, `findmnt`, and `df` connect device, filesystem, UUID, mount point, and capacity evidence.

In the field

A runbook says expand `/var`, but you need to identify the backing device and filesystem first.

Worked command

$ lsblk -f$ findmnt /var$ df -h /var$ blkid
Anti-pattern

Do not act on raw `/dev/sdX` names until you have verified the target from multiple signals.

Safer pattern

Record device, filesystem, UUID, mount point, and capacity before any change.

Knowledge check

A runbook says expand /var. Why must you treat the mount point /var as separate from its block device?

  • A /var is a path where a filesystem is attached; the backing device can change names across reboots
  • B /var is itself a block device, so writing to it is the same as writing to /dev/sda
  • C Mount points and devices are interchangeable as long as the UUID matches
  • D /var has no relation to any device until you run mkfs on it
Show the answer

Correct: A. /var is a path where a filesystem is attached; the backing device can change names across reboots

Why

A mount point is just where a filesystem is grafted into the tree; the kernel may enumerate /dev/sdX differently across boots, so you confirm the target via findmnt and the UUID from blkid. Treating /var as the device itself is the misconception that gets the wrong disk wiped.

Practice checklist

  1. Run read-only storage checks or use sample output.
  2. Map one mount point to a device and filesystem.
  3. Name the stable identifier.

Deliverable evidence

  • A device/filesystem/mount table.
Teaching diagramch11 · mental model
device -> filesystem -> mount, layered through LVM /dev/sda block device (lsblk) PV -> VG -> LV pvs / vgs / lvs ext4 / xfs filesystem (blkid) /var (mount) findmnt / df -h grow: lvextend -r -r resizes the filesystem too lvcreate -s snapshot of origin LV snapshot fills -> rollback lost (not a backup) verify from many signals before any destructive command

shows: How a mount point sits on a filesystem, on an LV stacked through VG and PV onto a block device, plus where growth and snapshots act.

does not prove: It is a schematic of the relationships, not evidence of your host's actual layout — only lsblk, findmnt, blkid, and lvs output prove that.

Memorize this

Commit these to memory, then drill them until recall is automatic.

lsblk -ffindmntblkiddf -h

Reference

lsblk -fdf -hi
Recall practice · Meaning -> command

cue One command that shows each block device with its filesystem type, UUID, and mount point

show recall target

lsblk -f

See this drill type Practice recall in the app