Linux Disk Space Troubleshooting: How to Find What Is Using Space

Linux disk space troubleshooting starts with evidence, not deletion. When a Linux server runs out of storage, services may fail, databases may stop accepting writes, and backups may not complete. The visible symptom rarely identifies the real cause.

This guide presents a careful sequence for finding the space. It uses standard commands such as df, du, and find. It also covers systemd journal growth, deleted files still held open, and database directories that need special care.

Confirm which filesystem is full

First, check filesystem capacity rather than guessing from one directory. The df command reports free and used blocks for mounted filesystems. Use human-readable units and include filesystem types when useful:

df -hT

Look at the Use% column and the mount point. A full root filesystem, such as /, requires a different investigation from a separate /var, /home, or database mount.

Inodes are another limit. Inodes track files and directories, so a filesystem can have free gigabytes but no capacity for new files. Check them with:

df -ih

If inode use is near 100 percent, look for very large numbers of small files. Mail queues, cache directories, temporary files, application sessions, and poorly controlled upload folders can create this pattern.

Record the output before making changes. Repeat df -h after a short interval to see whether a service is actively consuming space. This Linux disk space troubleshooting step gives you a baseline.

Map the largest top-level directories

Once you know the full mount, use du to measure directory contents. Run it against the relevant mount point, not the entire server by default:

sudo du -xhd1 / 2>/dev/null | sort -h

The -x option keeps the scan on one filesystem. That matters because mounted filesystems can otherwise appear inside the result and confuse the comparison with df. The -h option makes sizes easier to read, while -d1 limits the first scan to one directory level.

On many Linux systems, /var deserves close attention. Logs, package caches, queues, container data, web uploads, and application state often live there. If it is large, continue with a narrower scan:

sudo du -xhd1 /var 2>/dev/null | sort -h

Repeat the process inside the largest result. For example, inspect /var/log, /var/lib, or a known application directory. Smaller scans finish sooner and reduce the chance of overlooking the important path. This Linux disk space troubleshooting approach keeps the search focused.

Do not assume that a directory is safe to empty because its name sounds temporary. Application data, queues, and database files may have relationships that a simple deletion breaks. See why server disk space problems cause outages for related risks.

Use find to identify unusually large files

Directory totals tell you where to look. The find command helps identify individual files that deserve review. This example searches regular files larger than 500 megabytes on the root filesystem:

sudo find / -xdev -type f -size +500M -printf '%s %p\n' 2>/dev/null | sort -n

The output lists bytes followed by the path. To make results easier to read, you can use a loop with du, although that adds processing time:

sudo find /var -xdev -type f -size +500M -print0 2>/dev/null | while IFS= read -r -d '' file; do du -h "$file"; done

Search for old files only after you understand the application that owns them. A timestamp does not prove that a file is disposable. An old backup may be required for recovery, and an old log may support an investigation.

• Which user and service created the file?
• Does the application still reference it?
• Is there a retention policy or backup copy?
• Will removing it affect compliance, recovery, or troubleshooting?

Use ls -lh, stat, and service documentation to gather context. Avoid commands that combine discovery with deletion. Separate the decision from the action.

Check systemd journal and ordinary logs

Linux servers often use systemd’s journal for structured service and system logs. Check its current disk usage with:

sudo journalctl --disk-usage

To inspect recent messages without exporting a huge amount of data, limit the time range:

sudo journalctl --since "24 hours ago" --no-pager

Look for repeated errors, restart loops, failed storage operations, or an application producing unusually frequent messages. A large journal may be a symptom rather than the root cause.

Traditional log files can consume space too. Compare the largest log directories with du, then inspect file names and rotation settings. Log rotation means moving or compressing older logs according to a policy. It does not guarantee that every application rotates correctly.

Before changing journal retention, confirm operational and compliance needs. Aggressive removal may erase useful evidence. The systemd documentation can help verify the service-management context around affected units.

Investigate deleted files that still consume space

Sometimes du shows less data than df reports. A common reason is a deleted file that a running process still has open. Linux removes the directory entry, but the process keeps the storage until it closes the file.

sudo lsof +L1

Review the command, process ID, user, and file size. A process writing to a deleted log can explain a large difference between filesystem usage and visible directory totals.

Do not kill a process simply because it appears in this list. Confirm which service owns it, whether it can be restarted, and whether a graceful reload closes the file. In some cases, restarting the responsible service releases the space. In others, a configuration correction or application-specific log handling is needed.

Capture evidence first. If the system is under active pressure, a technician may need to prioritize service stability while preserving enough information to identify the cause.

Examine databases without touching live files

Database storage needs a separate investigation. A database directory may contain table data, indexes, write-ahead logs, binary logs, temporary files, or recovery files. Names and retention rules vary by database engine and deployment.

sudo du -xhd1 /var/lib 2>/dev/null | sort -h

Then identify the database service and review its configured data path, log path, and retention settings. Service status can provide useful context:

sudo systemctl status postgresql --no-pager

The service name may differ. Do not copy this example blindly on a server that uses MySQL, MariaDB, MongoDB, or another engine.

Ask the database administrator or application owner whether growth comes from business data, indexes, temporary work, transaction logs, or replication retention. Database commands can provide logical size information, but they must match the engine and version. Never delete files inside an active database data directory as a first response.

Safe options may include an approved backup, an engine-supported purge, a retention adjustment, moving data to an appropriately prepared volume, or planned maintenance. Each option requires verification before execution.

Compare df and du results

A useful diagnostic step is to compare the filesystem total from df with visible file totals from du. Small differences are normal because of filesystem metadata and rounding. Large differences need explanation.

• Different mount boundaries: du may cross or exclude mounts unless you use -x.
• Deleted-open files: a running process may retain space after deletion.
• Reserved blocks: filesystems may reserve capacity for system use.
• Snapshots or copy-on-write data: storage layers may hold blocks outside ordinary directory totals.
• Rapid growth: the numbers may change while the scan runs.

Repeat measurements at a known time and record the commands. This creates a clearer timeline than relying on memory. Google’s effective troubleshooting guidance also emphasizes evidence, hypotheses, and controlled testing.

Choose a safe next step

After locating the growth, classify it before changing anything. Separate normal business data from unexpected growth, temporary data, logs, and abandoned artifacts. Then confirm ownership and recovery options.

1. Preserve relevant output and recent error messages.
2. Identify the service, application, or user responsible.
3. Check backups and confirm that recovery procedures work.
4. Review retention rules before removing or compressing data.
5. Make one controlled change, then measure df and service health again.

Do not use broad commands such as recursive deletion across /var, /usr, or a database path. Do not truncate an active file without understanding how the application handles it. Also avoid rebooting as a substitute for diagnosis; a reboot may release an open file but can hide the cause and create additional downtime.

When to involve a Linux server specialist

Linux disk space troubleshooting becomes more sensitive when the full filesystem hosts a database, mail queue, virtual machines, containers, or production websites. It also requires extra care when df and du disagree, deleted-open files appear, or the server continues filling after a restart.

Tech Rescue Ops LLC can help collect evidence remotely, identify the responsible service, and plan a controlled remediation. For broader guidance, review the Linux server support service page. Careful Linux disk space troubleshooting is appropriate when the cause is unclear or cleanup could interrupt a business service.