Disk Usage and Management (df, du, mount)
A Linux system rarely has a single flat storage volume. Instead it typically composes several block devices, partitions, logical volumes, and even network shares into one unified directory tree. Understanding how much space is used, where it is being consumed, and how a given path maps to a physical or virtual device is a daily operational skill. Three tools dominate this work: df reports filesystem-level free space, du reports how much space a directory or file actually occupies, and mount (together with /etc/fstab) controls how storage devices are attached into the tree. These tools query different layers of the kernel's storage subsystem, which is why df and du can disagree even when inspecting the same path.
Cricket analogy: A Linux filesystem tree assembled from many devices is like an international XI squad drawn from different boards, and just as a scorer (df) and a fielding coach's tally (du) might report slightly different numbers for the same innings, they're measuring different things.
Filesystem-Level Reporting with df
df (disk free) reads superblock statistics for each mounted filesystem and reports total size, used space, available space, and use percentage. Because it operates on filesystem metadata rather than walking directory trees, df is essentially instant regardless of how many files exist. The -h flag renders sizes in human-readable units (K, M, G), and -T adds the filesystem type column, which is invaluable when diagnosing whether a mount is ext4, xfs, tmpfs, overlay, or a network filesystem like nfs. df -i switches the report to inode usage instead of block usage — a filesystem can report plenty of free bytes yet still refuse to create new files if its inode table is exhausted, a classic and confusing failure mode on filesystems hosting millions of small files (mail spools, session caches).
Cricket analogy: df reading superblock stats instantly is like a scoreboard operator glancing at the summary total rather than replaying every ball, and df -i checking inode exhaustion is like discovering a stadium has plenty of empty seats (bytes) but has run out of ticket numbers (inodes) to issue.
# Human-readable summary of every mounted filesystem
df -h
# Add filesystem type column
df -hT
# Check a specific mount point
df -h /var
# Inode usage (files exhausted != bytes exhausted)
df -ih
# Exclude tmpfs/devtmpfs pseudo-filesystems from the report
df -h --exclude-type=tmpfs --exclude-type=devtmpfsDirectory-Level Reporting with du
du (disk usage) walks a directory tree and sums the allocated block size of every file it finds, recursively. Unlike df, du can be slow on directories containing millions of files because it must stat each one. The most common invocation is du -sh <dir> to get a single human-readable total for a directory, and du -h --max-depth=1 <dir> to see a one-level breakdown of which subdirectories are consuming the most space — the go-to command when a disk is filling up and you need to find the culprit. du reports apparent allocated space (rounded up to filesystem block size and accounting for sparse files), which is why du and 'ls -l' sizes for the same file can differ, and why summing du across many small files yields more overhead than the sum of their logical byte sizes would suggest.
Cricket analogy: du walking every file to sum space, unlike df's instant read, is like a groundsman physically measuring every blade of grass on the outfield rather than reading a summary sign, and du -h --max-depth=1 is like checking each stand's usage one level at a time to find which section is overcrowded.
# Total size of a directory, human-readable
du -sh /var/log
# One level deep breakdown, sorted by size (largest last)
du -h --max-depth=1 /var | sort -h
# Find the 10 largest directories under /home
du -h --max-depth=2 /home 2>/dev/null | sort -rh | head -n 10
# Apparent size (logical bytes) instead of allocated blocks
du -sh --apparent-size /var/lib/dockerdf and du can legitimately disagree. A file that has been deleted but is still held open by a running process no longer appears when du walks the tree, yet the space it occupies is not released until the last file descriptor closes — so df still reports it as used. Find such 'phantom' space consumers with lsof +L1 or lsof | grep deleted, then restart or signal the offending process to release the space.
Mounting and /etc/fstab
Mounting is the act of attaching a filesystem (from a block device, partition, LVM logical volume, ISO image, or network share) to a directory in the existing tree, making its contents accessible at that path. The mount command performs this attachment for the current session; lsblk and blkid help identify available block devices and their filesystem types and UUIDs before mounting. For persistence across reboots, entries are added to /etc/fstab, which the boot process reads to mount filesystems automatically. Each fstab line specifies the device (preferably by UUID rather than a device name like /dev/sda1, since device enumeration order can change between boots), the mount point, filesystem type, mount options, dump flag, and fsck pass order.
Cricket analogy: Mounting a filesystem to a directory is like assigning a guest player to bat at a specific position in the order, while lsblk/blkid identifying devices beforehand is like checking a player's registration ID rather than their jersey number, since squad numbers (device names) can be reassigned between matches.
# List block devices and their filesystem types
lsblk -f
# Get the UUID of a partition
blkid /dev/sdb1
# Mount a device manually to a mount point
sudo mkdir -p /mnt/data
sudo mount /dev/sdb1 /mnt/data
# Mount using type and options explicitly
sudo mount -t ext4 -o defaults,noatime /dev/sdb1 /mnt/data
# View currently mounted filesystems
mount | column -t
findmnt /mnt/data
# Unmount safely
sudo umount /mnt/data
# Example /etc/fstab line (UUID-based, persists across reboots)
# UUID=3a1e4f2b-... /mnt/data ext4 defaults,noatime 0 2
# Test fstab entries without rebooting
sudo mount -aNever edit /etc/fstab and reboot blindly without testing. A malformed entry (wrong UUID, missing mount point, typo in filesystem type) can drop the system into an emergency shell during boot, especially if the entry lacks the 'nofail' option for removable or network storage. Always validate with sudo mount -a first, and consider adding nofail to entries for non-critical filesystems so a missing device does not block boot entirely.
Freeing Space Safely
When df reports a filesystem nearing capacity, a disciplined workflow finds the offender before deleting anything. Start broad with du --max-depth=1 at the root of the filesystem in question, then drill into the largest subdirectory repeatedly until you reach specific files. Common space hogs include unrotated log files in /var/log, orphaned Docker images and volumes, old kernel packages retained by apt, and core dump files. journalctl --vacuum-size and apt-get clean / apt-get autoremove are common remediation commands, alongside truncating (not deleting, if a process holds the file open) oversized logs with : > /path/to/logfile.log or truncate -s 0.
Cricket analogy: Drilling into du --max-depth=1 repeatedly to find a disk hog is like a coach reviewing team performance broadly, then drilling into the worst-performing department — batting, bowling, fielding — round by round, until pinpointing exactly which player's stats need attention, before deleting anything, verify it first.
- df reports filesystem-level free space instantly by reading superblock metadata; du reports actual space consumed by walking a directory tree, which is slower on large trees.
- df -i shows inode usage — a filesystem can be 'full' on inodes while still showing free bytes, a common issue with many small files.
- du -h --max-depth=1 <dir> | sort -h is the standard first command for locating what is consuming disk space.
- df and du can disagree when a deleted file is still held open by a running process; find these with lsof +L1 or lsof | grep deleted.
- Persistent mounts belong in /etc/fstab, referenced by UUID (via blkid) rather than device name, and should be tested with
mount -abefore rebooting. - Add the
nofailfstab option for non-critical or removable filesystems to avoid boot failures if the device is absent.
Practice what you learned
1. Why can `df` report a filesystem as nearly full while `du` on the same mount point shows much less space in use?
2. Which command shows inode usage rather than block/byte usage for mounted filesystems?
3. What is the primary purpose of /etc/fstab?
4. Why is it recommended to reference devices in /etc/fstab by UUID instead of a device path like /dev/sdb1?
5. What is the safest way to test new /etc/fstab entries before rebooting?
Was this page helpful?
Previous
Basic Networking Commands (ping, curl, ss)
Next
Reading and Managing Logs (journalctl, /var/log)
You May Also Like
Reading and Managing Logs (journalctl, /var/log)
Master the two dominant Linux logging models — the systemd journal and traditional flat-file logs in /var/log — to diagnose issues and manage log retention.
The Linux Filesystem Hierarchy
A tour of the standard Linux directory tree defined by the Filesystem Hierarchy Standard (FHS) — what lives under /etc, /var, /usr, /home, and more, and why the layout matters.
systemd and Managing Services
Learn how systemd manages services, sockets, and timers as units, and how to start, stop, enable, and inspect them with systemctl and journalctl.
Package Management (apt and yum)
Learn how Debian/Ubuntu's apt and RHEL/CentOS's yum/dnf install, update, and remove software, resolve dependencies, and manage repositories.
Related Reading
Related Study Notes in DevOps
Browse all study notesNginx Study Notes
DevOps · 30 topics
DevOpsAnsible Study Notes
DevOps · 30 topics
DevOpsAdvanced Kubernetes Study Notes
Kubernetes · 30 topics
DevOpsAdvanced Bash Scripting Study Notes
Bash · 30 topics
DevOpsApache Kafka Study Notes
Kafka · 30 topics
DevOpsDocker & Kubernetes Study Notes
YAML · 40 topics