Disk Space & Storage Management

In one line

A server that silently runs out of disk space fails in bizarre, hard-to-diagnose ways — df and du are the two commands that let you see a disk-space problem coming before it becomes an outage.

0/5 · 0%

Think of it like this

Real-life example: df (disk free) is like checking the total remaining capacity of a warehouse; du (disk usage) is like walking through it to see exactly which section is taking up all the space — one tells you THAT you have a problem, the other tells you WHERE it's coming from.

Key ideas

01
df -h (-h for human-readable sizes — GB/MB instead of raw byte counts) shows every mounted filesystem, its total size, how much is used, and crucially the USE% column — a server hitting 100% on its root filesystem is a genuinely serious, imminent problem, since almost nothing can write new data (including logs, and sometimes even the ability to SSH in cleanly) once a disk is completely full.
02
du -sh <directory> shows the total size of a directory (-s for summary, don't recurse into every subdirectory individually; -h for human-readable). du -sh */ | sort -rh (combining Phase 2's sort) lists every subdirectory's size, largest first — the standard first move when you know disk usage is high somewhere under a directory but don't yet know exactly where.
03
The single most common disk-space culprit on a real server is UNBOUNDED LOG GROWTH — an application logging verbosely with no log rotation configured can fill a disk over weeks or months of otherwise normal operation, a genuinely common, entirely preventable cause of production outages.
04
logrotate is the standard Linux tool for automatically managing log growth — it compresses, archives, and eventually deletes old log files on a schedule you configure, so a service's logs never grow unbounded. Most installed services (nginx, systemd's own journald) already ship with a sensible logrotate configuration; custom applications often need one added explicitly.
05
find / -size +100M -type f 2>/dev/null (from Phase 2's find, reused here) hunts down large files anywhere on the system — genuinely useful once df has told you a filesystem is nearly full and you need to find exactly what's consuming that space.

In your stack

→
A Spring Boot app configured with verbose DEBUG logging in production (rather than INFO or WARN) is a classic real cause of runaway log growth — du -sh /var/log/myapp catching this early, well before df shows the disk itself in real danger, is exactly the kind of proactive check worth running periodically rather than only after something breaks.

Code & diagrams

DfVsDudiagram

df tells you THAT a filesystem is full; du (aimed progressively deeper) tells you WHERE the space actually went.

Rendering diagram…

disk-checks.shmarkdown

The standard investigation sequence when disk space is a concern.

# Overall disk usage per filesystem — check the Use% column
df -h

# Total size of a specific directory
du -sh /var/log

# Which subdirectory under /var/log is the biggest?
du -sh /var/log/*/ | sort -rh | head -10

# Find any individual file over 100MB anywhere on the system
find / -size +100M -type f 2>/dev/null

# See a logrotate config for a real service
cat /etc/logrotate.d/nginx

myapp-logrotatemarkdown

A minimal logrotate config for a custom application's log file.

# Save as /etc/logrotate.d/myapp
/var/log/myapp/*.log {
    daily
    rotate 14
    compress
    missingok
    notifempty
    copytruncate
}

Explain it without notes

Why does a completely full disk cause a server to fail in ways that can be genuinely confusing to diagnose, beyond the obvious 'can't write new files'?

What's the difference between what df and du each tell you, and why do you usually need both when investigating a disk-space problem?

Practice

Run df -h on any Linux machine you have access to and identify which filesystem has the highest Use% — is it a cause for concern yet?

Use du -sh on a few top-level directories you have read access to and rank them by size, then drill one level deeper into the largest one to see what's actually consuming that space.

Trade-offs

↔
Aggressive log retention (keeping logs for a long time) is valuable for debugging historical incidents, but directly trades against disk space — logrotate's rotate N setting (how many rotated archives to keep) is exactly this trade-off made explicit and configurable, and the right value genuinely depends on how much history you actually need versus how much disk you can afford to dedicate to it.

Done when you can

I can check overall disk usage with df -h and identify a filesystem approaching capacity.
I can use du -sh to drill down and find exactly what's consuming disk space.
I understand why unbounded log growth is a common cause of disk-space incidents, and what logrotate does about it.

Command Palette