How to Check Disk Space on Linux

Running out of disk space can turn a routine deployment into an outage. Logs stop writing, databases cannot create temporary files, and package updates fail at the least convenient time. A short, repeatable inspection process makes the cause clear before you start deleting anything.

Start with filesystem capacity

Use df first. It reports space usage for mounted filesystems, rather than adding up individual directories.

df -h

The -h option formats sizes in units such as GiB and MiB. Focus on these columns:

• Filesystem: the device or logical volume behind the mount.
• Size, Used, and Avail: total, consumed, and available capacity.
• Use%: the proportion currently used.
• Mounted on: the directory where that filesystem is accessible.

A typical result might show / nearly full while /home has plenty of free space. That distinction matters: removing files under /home will not relieve a separate full root filesystem.

To inspect a specific mount point, pass it directly:

df -h /
df -h /var

Check inode exhaustion too

Disk blocks are not the only finite resource. Each file consumes an inode. A filesystem with millions of tiny files can run out of inodes even when df -h reports free storage.

df -i

Look at IUse%. A value near 100% means new files cannot be created on that filesystem. In that case, finding and reducing large files will not solve the immediate problem; you need to locate an excessive number of small files, often in cache, spool, session, or temporary directories.

Find the directory consuming space

Once df identifies the affected mount, use du to summarize directories on that same filesystem.

For a full root filesystem, this is a useful starting point:

sudo du -xhd1 / | sort -h

The options are deliberate:

• -x stays on one filesystem, avoiding misleading totals from mounted volumes.
• -h uses readable sizes.
• -d1 limits output to the first level of directories.
• sort -h orders the results by size.

The output points to the next directory to inspect. If /var is largest, narrow the scope:

sudo du -xhd1 /var | sort -h
sudo du -xhd1 /var/log | sort -h

Repeat until you have a specific directory or file category.

For a single directory, a compact summary is enough:

sudo du -sh /var/log

du measures allocated disk blocks. Its total can differ from df for reasons discussed below, so treat it as a tool for narrowing the search, not as the only source of truth.

Locate unusually large files

After identifying a suspect path, use find to list files above a meaningful threshold. This command searches within /var for files larger than 500 MiB:

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

The byte counts are easy for programs to sort accurately. If you prefer human-readable output, review the paths first and then inspect candidates with ls:

sudo ls -lh /var/log/example.log

Common sources include:

• Rotated logs that were not compressed or removed.
• Application debug logs left enabled after troubleshooting.
• Package caches and temporary build artifacts.
• Database dumps, backups, or uploaded media stored on the wrong volume.
• Container images, writable layers, and unused volumes.

Do not delete a large file solely because it appears in a list. Establish what created it, whether a running service has it open, and whether it is covered by a retention or backup policy. For container hosts, inspect storage through the container runtime as well as the host filesystem; Docker container monitoring helps keep resource use visible alongside host metrics.

Resolve the df and du mismatch

Sometimes df shows a full filesystem, but the directory totals from du seem much smaller. The most common cause is a deleted file that a process still has open. The directory entry is gone, so du cannot see it, but the blocks remain allocated until the process closes the file.

On systems with lsof, inspect open-but-deleted files:

sudo lsof +L1

Review the process and file carefully. Restarting or gracefully reloading the owning service may release the space, but make that change according to the service's operational requirements. Killing a database or web process just to reclaim space can create a larger incident.

Other explanations include snapshots, mount points included in an earlier scan, sparse files, and filesystem metadata. Re-run df -h after each corrective action so you are measuring the affected filesystem rather than assuming success.

Clean up without creating a second problem

Prefer controlled cleanup mechanisms over ad hoc deletion:

1. Rotate or compress logs using the system's log rotation policy.
2. Remove application artifacts only after confirming they are reproducible or retained elsewhere.
3. Clear package caches with the package manager, not by guessing at its internal files.
4. Move durable backups or uploads to the volume intended for them.
5. Add a retention policy so the same directory does not grow indefinitely.

If the server has little free space, make a small, reversible change first and verify capacity. Freeing enough headroom to restore normal writes is usually safer than a broad cleanup performed under pressure.

Turn a one-off check into monitoring

A disk incident is easier to handle when growth is visible before the filesystem is full. Track capacity for each important mount point, and choose an alert threshold that leaves time for investigation, cleanup, or expansion. Thresholds should reflect the workload: a fast-growing log volume needs more free-space headroom than a mostly static system partition.

CloudStats can provide a central view of server metrics and email alerts for conditions you define. Review its Linux server monitoring features to see whether it fits your operating routine, and use the server monitoring overview to build a broader baseline.

A practical disk-space checklist

When an alert or failed write points to storage, use this order:

1. Run df -h to identify the full mounted filesystem.
2. Run df -i to rule out inode exhaustion.
3. Use du -xhd1 on that mount and progressively narrow the largest directory.
4. Use find to inspect unusually large files.
5. Check lsof +L1 if df and du disagree.
6. Apply the narrowest safe cleanup, then verify with df -h.
7. Correct the retention rule, deployment behavior, or capacity plan that allowed recurrence.

The commands are simple, but their sequence prevents a common mistake: acting on the largest visible file instead of the resource that is actually exhausted.