Disk: df, du, and inodes

The commands df -h, df -i, and du tell you how full a Linux disk is and where the space went. df -h reports free bytes in a readable size. df -i reports free inodes, which are the name slots every file needs. A volume can look only partly full in bytes and still refuse new writes when every inode is used by millions of tiny files.

Treat the two readings as a comparison, not as one number. Bytes-full usually means a large file or a pile of large files. Inode-full means a pile of names, such as PHP sessions, Maildir messages, thumbnails, or a cache that never cleans up. du then shows which directory holds the bulk so you know where to look next.

df -h; df -i; du -xh –max-depth=2 / | sort -h | tail

Read df -h first for filesystem, size, used space, available space, and mount point. Then run df -i on the same mounts for inode counts. If inode Use% is 100 and bytes are not, stop thinking only in gigabytes. The du -xh --max-depth=2 / line stays on one filesystem with -x and prints human sizes two levels down. Piping through sort -h | tail puts the largest directories at the bottom so you open the right path next.

Bytes versus inodes

A multi-gigabyte error_log is a bytes problem. Twenty million empty session files under /tmp or a PHP sessions path is an inodes problem. Leftover backup copies and forgotten staging sites are usually bytes again. When /tmp fills in a tight loop, look for a debug dump or a process that cannot finish a sort. Find the writer with lsof or by modification time, then delete with a clear plan.

On shared hosting you see account quota in cPanel rather than a raw df of the whole node. The same split still applies: file size versus how many files the account holds. On a VPS, df is the first command on a disk ticket, and skipping it only leads to guessing.

What to remove and what to leave alone

After du names a directory, check modification times before you empty it. A recent staging copy may be safe to clear if you still have an off-box backup. Old mail in a catch-all mailbox needs a conversation with the account owner, not a blind delete. Current access logs under a cPanel home often rotate on the server; deleting the active log only leaves you without history for the incident you are fixing.

On a VPS, leftover container layers and old kernels under module paths are common byte consumers, not inode storms. Prefer the package manager’s autoremove tools over a hand-built find-and-delete from a late-night forum post. If you are on shared hosting without root, use cPanel File Manager, disk usage tools, and WP Toolkit where they apply, and open a ticket with us if the account quota still will not clear.

A short order of checks

1. Run df -h and df -i and compare Use% on the same mount.
2. If inodes are exhausted, hunt for huge counts of small files rather than one giant file.
3. Use du with a modest depth to name the heavy directories, then inspect before delete.
4. Leave database data directories, live mail you still need, and active logs alone until you have a restore path.

That sequence keeps a “disk full” ticket factual. You learn whether the limit is bytes or names, where the weight sits, and what is safe to reclaim without breaking the site.