Zero9THE UNKNOWN.
Linux & Systems

A Safe 90-Second Linux Disk Space Triage

A read-only sequence for finding what filled a Linux server before deleting logs, images, caches, or data you may still need.

3 min read
#linux#disk-space#docker#troubleshooting

An exposed hard disk drive

Photo by Denny Müller on Unsplash.

A nearly full VPS encourages bad decisions. The fastest-looking command is often a recursive delete copied from an old forum post.

Start with read-only checks instead. The goal of the first 90 seconds is not to reclaim space; it is to identify which filesystem is full and which subsystem owns the data.

The commands below target GNU/Linux. Run them with an account that has the required permissions.

1. Confirm the filesystem

df -h

Look at the Use% and Mounted on columns. A full root filesystem, a separate /var filesystem, and an exhausted container volume are different problems.

If free bytes look reasonable but applications still report No space left on device, check inode usage:

df -ih

A very large number of tiny files can exhaust inodes before it exhausts storage capacity.

2. Find the large top-level directory

Stay on the affected filesystem so mounted backups and network storage do not distort the result:

sudo du -x -h --max-depth=1 / 2>/dev/null | sort -h

If /var is the largest entry, narrow the search:

sudo du -x -h --max-depth=1 /var 2>/dev/null | sort -h

Repeat only inside the directory that is actually large. This is slower than guessing, but considerably faster than restoring deleted data.

3. Check common service-owned storage

For systemd journals:

journalctl --disk-usage

This reports the combined size of active and archived journal files. Do not assume the journal is the cause until the number supports it.

For Docker:

docker system df
docker system df -v

The verbose view separates image, container, volume, and build-cache usage. Pay attention to what is active, not only what Docker labels reclaimable.

4. Look for deleted files still held open

Sometimes du cannot explain the space shown by df. A process may still have a deleted file open; the directory entry is gone, but the filesystem cannot release its blocks until the process closes the file.

If lsof is installed:

sudo lsof +L1

Identify the owning process and service before restarting anything. A controlled service restart is normally safer than killing an unfamiliar PID.

Cleanup comes after ownership

Only choose a cleanup action after the data has an owner:

  • rotate or limit a verified oversized journal;
  • remove an application cache using that application’s supported command;
  • adjust retention for backups or generated artifacts;
  • inspect Docker objects individually before pruning them;
  • expand the filesystem when the retained data is legitimate.

Treat docker system prune as a destructive command, not a diagnostic one. Docker documents exactly which stopped containers, networks, images, and build cache it may remove; adding --volumes broadens that scope further.

The short version is: df identifies the filesystem, du identifies the directory, and service-specific tools identify the owner. Delete only after all three answers agree.

References