Inode Limits: The Hidden Cap That Fills Before Disk Does

Most hosting dashboards show you a single number for storage: gigabytes used out of gigabytes allowed. That number can look perfectly healthy while your account is actually full. The culprit is a second, quieter limit called an inode, and on a lot of hosting plans it runs out long before the disk does.

If you have ever seen an error like “disk quota exceeded” while your usage bar sits at 40 percent, this is almost always the reason. Here is what inodes actually are, why WordPress sites burn through them faster than you would expect, and how to clean house before uploads and email start failing.

What an inode actually is

An inode is a data structure the filesystem uses to store metadata about a file or directory: its owner, permissions, timestamps, and the location of its data on disk. Every single file and every single folder on your account consumes one inode, regardless of how large or small that file is. A one-byte text file and a 500 MB video use the same single inode for their metadata entry.

Most shared and managed hosting plans cap the number of inodes an account can use, separately from the disk space cap. That limit exists because filesystems only reserve a fixed number of inode slots when they are formatted. Once every slot is used, the filesystem cannot create a new file, even if there are gigabytes of free space sitting unused. WordPress does not care that space is available; if it cannot get an inode to write a new file, the upload, the cache write, or the incoming email simply fails.

Why WordPress sites fill up fast

A single WordPress install can generate a surprising number of small files without anyone touching the media library. The usual suspects:

• Post revisions. Every autosave and manual save can add rows to the database, but revision-related attachments and some page builder plugins also write files to disk for each version.
• Full-page cache files. LiteSpeed Cache and similar full-page caching systems store a static HTML file (often several, for different device types and logged-in states) for every page and post. A site with a few thousand pages can generate tens of thousands of cache files.
• Session and transient files. Plugins that use file-based transients or session handling instead of a database or object cache can leave behind large numbers of small files that never get cleaned up.
• Email. If your hosting account also handles mail, every message sitting in an inbox, including spam folders, counts as its own file. Accounts that have been collecting mail for years, especially with attachments, are a common source of runaway inode counts.
• Backups stored on the same account. Local backup plugins that keep multiple full-site archives, unzipped, on the same disk multiply your file count fast, especially if they back up node_modules, cache directories, or vendor folders along with everything else.
• Log files. Debug logs, access logs, and plugin-specific logs that rotate daily or hourly without cleanup can accumulate into thousands of small files over a year.

None of these individually look alarming. Combined, on a plan with a five- or six-figure inode cap, they add up faster than most site owners expect, particularly on sites that have been running for several years without a cleanup.

Checking your actual usage

Your hosting control panel usually shows an inode count separately from disk usage; look for it under storage or resource usage. If you have shell access, you can get a rough count of files in any directory with:

find /path/to/site -type f | wc -l

Running that against your wp-content/cache, wp-content/uploads, and mail directories separately will usually reveal where the bulk of your files live. On systems where you have access to df, the -i flag shows inode usage at the filesystem level:

df -i

Cleaning up with wp-cli

wp-cli is the standard command line tool for WordPress administration, and it is the fastest way to clear out the WordPress-generated clutter that eats inodes. A few useful commands:

Delete all post revisions:

wp post delete $(wp post list --post_type=revision --format=ids) --force

Clear all transients, including expired ones sitting in the database or as orphaned files:

wp transient delete --all

Flush the object and page cache:

wp cache flush

If you are running LiteSpeed Cache, its own wp-cli commands or the plugin’s admin panel purge option will clear the static cache directory, which is usually the single biggest source of small files on a busy site. Pairing LiteSpeed’s full-page cache with Redis or Memcached for object caching keeps most of that caching activity in memory rather than on disk, which sidesteps the inode problem for that layer entirely.

Preventing the next pile-up

A few habits keep inode counts under control without any ongoing effort:

1. Set a revision limit in wp-config.php so WordPress does not keep unlimited copies of every post edit: define('WP_POST_REVISIONS', 5);
2. Configure your cache plugin to purge stale entries automatically rather than letting cache files accumulate indefinitely.
3. Store backups offsite (a remote bucket or a backup service) instead of leaving unzipped archives on the same hosting account.
4. Clean out old mailboxes and disable storing large attachments in the inbox where webmail access allows it.
5. Rotate and cap log files rather than letting plugins log indefinitely.

A managed host that monitors resource usage on your behalf, which is one of the things ServerBorn’s NVMe-backed plans handle automatically, can catch an inode spike before it becomes an outage, but it is still worth knowing what is filling up your account and why.

The takeaway

Disk space and inode count are two separate limits, and the second one is invisible on most dashboards until it bites. Caches, revisions, mail, and backups are the usual causes on a WordPress site. A quick audit with find or your host’s resource panel, followed by a cleanup pass with wp-cli, will usually buy back plenty of headroom without upgrading a plan you do not actually need more disk space on.