Updated 2026-09-23

Linux disk usage suddenly spikes: check space, inodes and growing logs

A database reports disk full, uploads fail, or a root filesystem approaches capacity. Before deleting anything, identify the affected filesystem and whether the shortage is storage space or inodes. These read-only examples target Linux; paths and available utilities depend on your installation.

1. Separate storage capacity from inode exhaustion

df -h
df -i

Record the mount point and observation time. Free bytes do not rule out inode exhaustion: many small files can exhaust a filesystem's available inodes. Correlate growth with deployments, imports, uploads and backup jobs.

2. Narrow the directory scan

sudo du -xhd1 /var
sudo du -xhd1 /home

These are example starting paths, not every possible data location. Use the path on the affected filesystem. On GNU du, -x avoids crossing into other filesystems and -d1 limits the displayed depth. Large scans can still create substantial I/O even though they do not delete files; start narrowly on busy servers. Permission errors can make the result incomplete.

3. Follow the evidence to the source

• Container storage: inspect docker system df and docker info --format '{{.DockerRootDir}}'. These help orient the investigation, but do not assume one storage summary accounts for every log file. If evidence points to container logs, follow the Docker log rotation guide.
• Application data: check the actual upload, backup and database directories. Do not delete database files or Docker volumes to make the alert disappear.
• System logs and caches: journalctl --disk-usage helps inspect journal storage on systemd systems. Look for a service repeatedly logging errors before deciding on retention changes.
• Deleted but open files: when df and directory totals disagree, an authorized operator can inspect sudo lsof +L1, if lsof is installed. A process may still hold a deleted file open. This is one possible explanation, not proof; identify the owner before planning a service action.

4. Review a change before freeing space

Keep the relevant error evidence. Confirm ownership and retention requirements before removing a cache or backup. Do not truncate Docker-managed logs, prune volumes or kill an unfamiliar process as a generic fix. For business data, arrange backups or snapshots on suitable storage before any approved archive or removal operation.

After an approved change, recheck capacity, inodes and the affected application's health. Watch whether growth resumes. An alert clearing does not establish that the underlying fault is resolved.

Illustrative example, not a customer incident

A root filesystem is nearly full while inode usage is normal. Directory checks point toward container storage, then a specific log shows rapidly repeated connection errors. Removing the log alone would not address the repeated errors. Investigate the connection failure and review log rotation. If inodes were exhausted instead, many small files would deserve attention rather than assuming the same log problem.

Ask AI for evidence, not automatic cleanup

Use read-only checks to compare disk space, inodes and the likely growing directories. Distinguish container logs, application data, caches and deleted files still held open. State what is confirmed and what remains unknown. Do not delete files, truncate logs or restart services. Propose any change with its risk, verification and rollback steps first.

In OpsMate, use the terminal and AI workspace to examine the results. Review actual commands and permissions; a prompt alone is not a security boundary. Remove secrets and personal information before submitting diagnostic output to cloud AI.

Troubleshooting guides