Disk and inode usage: the limit nobody watches

Disk space is the limit everyone watches. Inodes are the limit that actually stops sites, and almost nobody looks at them until an account with plenty of free space starts refusing to write files.

Two separate ceilings

• Disk: how many bytes you may store.
• Inodes: how many files and directories you may have, regardless of size.

A hundred thousand one kilobyte cache files use almost no disk and a hundred thousand inodes. That is why an account can report ten percent disk usage and still fail to save an upload. The error is usually a generic write failure, which sends people looking in entirely the wrong place.

Where the inodes actually go

In practice, on a WordPress network, four things:

1. Cache directories. Page caches, optimisation caches and thumbnail caches generate enormous numbers of tiny files.
2. Old backups kept on the account. Especially uncompressed ones, and especially several generations of them.
3. Mail. Every message is a file. A mailbox with a decade of newsletters is tens of thousands of inodes.
4. Media thumbnails. One upload becomes many derivative sizes, multiplied by every theme and plugin that registers its own.

Finding the culprit

du -sh ~/*                       # disk, by top level directory
find ~ -xdev -type f | wc -l     # total file count
for d in ~/*/; do echo -n "$d "; find "$d" -type f | wc -l; done

The last line gives you file counts per directory, which is what you need. Sort the output and the answer is almost always obvious: one directory holding an order of magnitude more files than the rest.

Cleaning up safely

• Caches: safe to purge. They rebuild. Do it through the application rather than deleting directories blindly.
• Backups on the account: download them off the server, then remove them. A backup stored on the thing it backs up is not protecting you anyway.
• Mail: archive or delete old messages. If mail is large on a site that does not need mail, that is worth questioning entirely.
• Thumbnails: reduce the number of registered sizes before regenerating, otherwise you rebuild the same problem.
• Logs: rotate them. An error log left for two years can be enormous on its own.

Be careful with bulk deletion. Removing a cache directory while the application expects it can break the site until it is recreated, which is why purging through the application is the safer route.

The network version of this problem

Because both limits apply per account, an account holding several sites shares one inode ceiling between them. One site with an aggressive caching plugin can therefore exhaust the quota for its neighbours, and the site that fails to write is not the site causing it.

That is worth remembering during diagnosis: on a multi-site account, check usage for the whole account, not just the site reporting the error. How to group sites so they do not do this to each other is covered in Network Planning.

Watch it before it bites

Both figures are visible in the panel. Add them to whatever periodic check you already run, alongside certificate expiry and cache hit rates, as described in Running Your Estate. An account trending toward its inode ceiling is visible weeks before it fails, and dealing with it then is a five minute job rather than an outage.

The quota interface is documented at docs.cpanel.net.