Checking Disk Usage

Running out of disk space is one of the most common reasons a Linux server suddenly breaks. Logs pile up, backups never get deleted, and a single runaway folder can fill an entire drive. The good news is that Ubuntu ships with two small but powerful tools that answer the two questions you will always ask: “How full are my disks?” and “What exactly is eating all that space?” This page shows you how to use df and du to find and fix disk problems fast.

Why disk space matters

When a disk fills up to 100%, programs that need to write data start failing. Databases refuse new writes, web servers can’t save uploads, and even logging in over SSH (Secure Shell, the standard way to access a remote server) can break because some shells need to write temporary files. Checking disk usage regularly is one of the most basic and important habits in server administration.

Two terms to know first:

• A filesystem is a formatted area of a disk that stores files. On Ubuntu the main one is usually mounted at / (the root of the directory tree).
• Mounted means a filesystem has been attached to a folder so you can read and write to it. For example, your data drive might be mounted at /data.

Checking filesystem usage with df

df stands for “disk free”. It reports how much space each mounted filesystem has and how much is used. This is your starting point: it tells you which disk is full before you go hunting for the cause.

Always run it with the -h flag, which means “human-readable” (sizes shown as 12G or 512M instead of raw blocks):

df -h

Output:

Filesystem      Size  Used Avail Use% Mounted on
tmpfs           393M  1.2M  392M   1% /run
/dev/sda2        49G   38G  8.5G  82% /
tmpfs           2.0G     0  2.0G   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
/dev/sda1       1.1G  6.2M  1.1G   1% /boot/efi
/dev/sdb1       100G   45G   55G  46% /data

The columns mean:

Column	Meaning
Filesystem	The device or pseudo-filesystem (e.g. /dev/sda2)
Size	Total capacity of that filesystem
Used	Space currently in use
Avail	Space still free
Use%	Percentage used — the number to watch
Mounted on	The folder where it is attached

The line to care about is usually / (your root filesystem). In the example above it is 82% full, which is getting risky.

Tip: Ignore the tmpfs lines. Those are temporary in-memory filesystems that live in RAM, not on your actual disk. They reset on reboot and are not where your storage problems hide.

When to use this

Run df -h first, every time, before anything else. It is fast and tells you which mount point to investigate. If / is fine but /data is full, you’ve already narrowed the search to one directory tree.

Checking inodes too

Sometimes df -h shows free space but writes still fail. The cause is running out of inodes (the metadata entries the filesystem uses to track each file — you get a fixed number when the disk is formatted). Millions of tiny files can exhaust inodes while space remains. Check with:

df -i

If IUse% is at or near 100%, you have too many files, not too little space — usually a cache or session directory gone wild.

Finding directory sizes with du

du stands for “disk usage”. While df looks at whole filesystems, du measures how much space individual folders take up. This is how you find the actual culprit.

The most useful form is du -sh, where -s means “summary” (one total per item instead of every subfolder) and -h again means human-readable:

sudo du -sh /var/log

Output:

3.4G    /var/log

We use sudo (run as the administrator) because du needs permission to read into protected folders; without it you get “Permission denied” warnings and wrong totals.

Finding the biggest directories

The real power move is listing the size of every top-level folder and sorting to find the biggest offenders. Run this from the root of the full filesystem:

sudo du -h --max-depth=1 / | sort -rh | head -n 10

Output:

38G     /
18G     /var
9.2G    /usr
6.1G    /home
3.4G    /var/log
2.0G    /opt
512M    /tmp
...

Breaking that command down:

• du -h --max-depth=1 / — show human-readable sizes one level deep under / (so you see /var, /usr, /home, not every nested file).
• | sort -rh — sort in reverse (-r) by human-readable numbers (-h), biggest first.
• | head -n 10 — keep only the top 10 lines.

Now drill down. If /var is huge, repeat the command one level deeper:

sudo du -h --max-depth=1 /var | sort -rh | head -n 10

Keep following the biggest number downward until you find the specific folder or file responsible. On most servers the answer is /var/log (runaway logs) or an old backup folder.

df vs du — which to use when

Tool	Answers	Use it when
df -h	How full is each filesystem?	First, to find which disk is full
du -sh	How big is this one folder?	To measure a known directory
du --max-depth=1 | sort -rh	What are the biggest folders here?	To hunt down what is filling the disk

Gotcha: df and du can disagree. If a program is still holding a deleted file open, the space stays used (df counts it) but du can’t see the file anymore. Find these with sudo lsof +L1, then restart the offending service to release the space.

Cleaning up safely

Once you find the cause, common safe cleanups on Ubuntu include:

# Remove cached .deb packages no longer needed
sudo apt clean

# Remove old, unused packages and kernels
sudo apt autoremove --purge

# Vacuum systemd journal logs older than 7 days
sudo journalctl --vacuum-time=7d

Never blindly delete files in /var, /usr, or /boot. Confirm what a file is before removing it, and never run rm -rf on a path you have not double-checked.

Best Practices

• Always start with df -h to find the full filesystem, then use du to drill into it.
• Use sudo with du so protected directories are counted correctly.
• Check df -i when space looks free but writes still fail — you may be out of inodes.
• Set up monitoring or a cron job to alert you before a disk hits 90%, not after it hits 100%.
• Keep logs under control with journalctl --vacuum-time and logrotate instead of deleting log files by hand.
• Reboot or restart a service if df and du disagree — deleted-but-open files are the usual cause.

Related Topics

• Disk management
• Mounting drives
• Memory and swap
• Monitoring resources
• Viewing logs with journalctl