Disks and Capacity: df, du, lsblk, mount
"No space left on device" — running out of disk is one of the most common server incidents, and it kills services en masse (can't write logs, databases, temp files). This article teaches the workflow to find and fix it: from "which filesystem is full" to "what's eating the space".
df: how much space each filesystem has left
df (disk free) gives an overview of capacity across filesystems:
df -h
Filesystem Size Used Avail Use% Mounted on
overlay 59G 22G 34G 40% /
tmpfs 64M 0 64M 0% /dev
/dev/vda1 59G 22G 34G 40% /etc/hosts
-h (human-readable) shows G/M instead of hard-to-read block counts. The most important columns are Use% and Mounted on: they tell you which filesystem is about to fill up and where it's mounted in the directory tree. When you get a disk-full alert, this is the first command — to know which one is full (a full / is very different from a full separate partition like /var).
The "df says there's space but it still reports disk full" trap: you may have run out of inodes (the number of files), not capacity. Each file costs one inode; too many small files exhaust the inodes even with GB free. Check with
df -i(look at the IUse% column).
du: which directory is eating space
df tells you which filesystem is full; du (disk usage) traces which directory inside it is eating space:
du -sh /usr # total size of /usr (-s summary, -h human)
du -sh /etc
100M /usr
672K /etc
To find the "culprit", list the size of each subdirectory then sort descending:
du -sh /usr/* | sort -rh | head
62M /usr/lib
25M /usr/bin
7.7M /usr/sbin
5.8M /usr/share
sort -rh sorts by human-readable number, descending (-r); head takes the first few. This is the pipeline (Article 6) you'll type a lot when tracing a full disk: run du -sh */ | sort -rh | head in the suspect directory, go into the largest one, repeat — digging down to where the space goes.
Find large files
When you want to target large files directly (Article 3 — find -size):
find / -type f -size +100M 2>/dev/null # files larger than 100MB
2>/dev/null (Article 6) discards the "Permission denied" errors when scanning the whole system, keeping it tidy. The culprit for a full disk is usually a bloated log (/var/log/*.log), a temp file, or a forgotten database dump.
A "disk full" workflow
Put it together into a workflow you can follow when the server reports a full disk:
1. df -h → which filesystem has high Use%? mounted where?
│
2. cd <that mount point>
du -sh */ | sort -rh | head → which directory is largest?
│ (repeat, dig deeper)
3. find . -type f -size +100M → which specific file is large?
│
4. fix it: delete/compress old logs, clear temp files, grow capacity
The two most space-hungry spots on a server: /var/log (logs that don't rotate) and temp files/cache. For systemd logs, clean up with journalctl --vacuum-size=200M (Article 15). For ordinary logs, compress/delete the old ones — but don't rm a log file that a process is actively writing to (it still holds the space); instead truncate it to empty with truncate -s 0 file.log or configure logrotate.
lsblk: view storage devices
df views filesystems; lsblk views block devices (physical disks and partitions):
lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
vda ... 59G 0 disk
└─vda1 ... 59G 0 part /
It shows the disks (disk) and their partitions (part), along with the mountpoint. Handy when attaching a new disk (for example, adding an EBS volume on cloud) — you see the new disk appear here before you mount it.
mount: attach a filesystem to the directory tree
Recall Article 2: Linux has a single directory tree. A disk/partition is only usable once it's mounted (attached) to a directory in that tree:
mount # list everything currently mounted
mount /dev/vdb1 /mnt/data # mount the partition at /mnt/data (needs root)
umount /mnt/data # unmount it
After mounting, everything you write into /mnt/data actually lives on that disk. To mount automatically at boot, add a line to the /etc/fstab file. Manual mounting is rare day to day, but you need it when adding disks to a server.
Environment note: in a container,
lsblk/mountreflect the host's devices (Docker Desktop's Linux VM), not your Mac — recall Article 1 of the Docker series. For full mount practice, a real Linux VM is more illustrative.
🧹 Cleanup
This article is mostly view commands, nothing created that needs cleaning up.
Wrap-up
When the disk is full: use df -h to see which filesystem is full (watch Use% and the mount point; df -i for inodes), then du -sh */ | sort -rh to dig down for the space-eating directory, and find -size to target large files — the culprit is usually a log in /var/log. lsblk views devices/partitions, mount attaches a disk to the directory tree. The df → du → find workflow is the standard playbook for handling "No space left on device".
So far we've used the tools that ship with the system. Article 11 covers how to add software: the package manager (apt, dnf, apk) — install, update, remove.