Inodes

On a Linux system, a file's name and content aren't enough: the system also has to know who owns it, who can read it, when it was modified and where its data blocks are. These metadata are stored in an inode. The inode(7) man page sums it up: each file has an inode containing metadata, and an inode number that is unique within the file system.

What an inode contains

• the type (regular file, directory, symbolic link, device) and the access permissions;
• the owner's user ID and the group ID;
• the size and the number of allocated blocks;
• the times of last access, last content modification and last status change;
• the number of hard links pointing to it.

So the permissions you set with chmod, such as 644 or 755, are stored in the inode. A directory uses an inode too, even an empty one.

Why hosts limit inodes

A file system has a fixed or capped number of inodes: once they run out, no new file can be created, even if free space remains. On shared hosting, the host therefore sets a quota per account. The cPanel blog points this out: the quota limits the number of files, not their size. The control panel often shows it as “File Usage.”

The quota often has two thresholds. Above the soft limit, files can still be created during a grace period; at the hard limit, creation is refused. CloudLinux, for example, lets hosts set both thresholds for the /home partition, with a seven-day grace period by default. Values vary a lot from one host to another: check the ones for your plan.

What uses up inodes on a WordPress site

• Media: for each uploaded image, WordPress creates one copy per image size registered by core, the theme and plugins. A media library of a few thousand photos quickly adds up to tens of thousands of files.
• Caches: page cache plugins often write one file per page, per device or per language; the cPanel blog lists caches among the big inode consumers.
• Email: in a mailbox stored on the hosting account, every message is a file.
• Backups and forgotten files: archives left on the server, old copies of the site, debug logs. They're also a security problem, covered in our article on exposed sensitive files.
• Faulty scripts that generate files in a loop, or a hacked site filled with spam pages.

For WordPress

• Measure: over SSH, df -i shows used and available inodes on each file system, and find wp-content -type f | wc -l counts the files in a folder.
• Clear caches from the plugin that created them, rather than deleting its folders by hand.
• Move backups off the server: a copy left on the same hosting account uses inodes and disappears along with it. The 3-2-1 rule calls for a copy elsewhere anyway.
• Cut down unneeded image sizes registered by the theme or plugins, then regenerate thumbnails with a suitable tool.
• A sudden, unexplained jump in the number of files is a warning sign: check that no folder is filling up with unknown PHP or HTML files.

Common mistakes

Assuming there's room left because the disk isn't full; deleting a cache folder while it's being rebuilt; forgetting about email, which can make up most of the files in an account.