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.

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).

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.

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.

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.