The Unified Tree Requires Assembly
We've established that Linux has one unified filesystem tree starting at /. But your computer likely has multiple storage devices — a main SSD, a secondary hard drive, a USB stick, a network share. How do they all fit into one tree?
The answer is mounting. To make a filesystem accessible, you attach (mount) it to an existing directory in the tree. That directory becomes the mount point — the doorway into that filesystem. Before mounting, the mount point directory may contain files; those files become temporarily hidden (not deleted) while something is mounted over them, and reappear when unmounted.
How Mounting Works
The mount command attaches a filesystem — a partition, a network share, a disk image, anything the kernel can present as a block device — to an existing directory, making its contents appear at that path. umount detaches it again, and refuses if something is still using it. Mount options tune the behavior of a given mount: read-only mounts are common for forensics or untrusted media, network filesystems like NFS are mounted by pointing at a remote host and export path instead of a local device, and an ordinary file can be mounted as if it were a disk via a loop device — the same mechanism container runtimes and disk image tools rely on.
Viewing Current Mounts
df -h lists every mounted filesystem along with its size, usage, and mount point. A typical layout might show the root filesystem on one partition while /home sits on a separate partition entirely — a common pattern that lets you reinstall the OS without touching user data — with /tmp backed by RAM via tmpfs (fast, and automatically cleared on reboot), and any external drives showing up at whatever path they were mounted to. findmnt gives the same information in a more detailed, tree-structured view that also shows filesystem type and mount options.
The /etc/fstab File: Persistent Mounts
Mounts created with the mount command are temporary — they disappear on reboot. For permanent mounts, Linux uses /etc/fstab (filesystem table), which the system reads at boot. Each line has six whitespace-separated fields: device, mount point, filesystem type, options, dump, and pass — for example, a root filesystem entry might read UUID=a1b2c3d4-... / ext4 defaults 0 1.
Key fields:
- device: What to mount — device path, UUID, or label
- mount point: Where to attach it in the tree
- type: Filesystem type (ext4, xfs, nfs, tmpfs, vfat, etc.)
- options: Mount options (ro for read-only, noexec to prevent executing files, noauto to skip at boot, size=4G for tmpfs)
- dump: Whether the dump backup utility should back this up (almost always 0)
- pass: Order for fsck filesystem check at boot (1 for root, 2 for others, 0 to skip)
Why UUIDs instead of device names:
Device names like /dev/sda1 are assigned by the kernel based on detection order. If you add a new disk, your old /dev/sda might become /dev/sdb, breaking your fstab. UUIDs are permanent identifiers embedded in the filesystem itself — they never change regardless of which port the drive is plugged into. The blkid utility reports the UUID (and filesystem type) for any block device, which is exactly the identifier you'd copy into an fstab entry.
Key Point: Separate partitions for /home, /var, and /tmp are a common production pattern, not just a curiosity. If /var/log fills up (a common failure mode), it only fills the /var partition — the root filesystem stays healthy and the system remains bootable. If /tmp is a tmpfs in RAM, a runaway process filling /tmp can't take down the disk. Partition layout is an architectural decision with real operational consequences.