One of the most common (and misunderstood) elements of a website and web hosting is the inode. If you run your own website or handle maintenance on any level at all, you will deal with inodes at some point. Whether that is through routine maintenance or attempting to fix an error, knowing what an inode is and how it affects your WordPress installation is imperative to your long-term success.
What is an Inode?
In a very general sense, an inode is a single file within your file system. For most users, thatβs enough information to deal with almost everything that they will come across.
More technically, however, an inode is where the metadata for files is stored on UNIX systems (Linux servers and Apple computers are UNIX based). Inodes are the table entries that are linked to by directories and filesΒ Inodes contain all sorts of information:
This metadata includes (1) the size of the file (in bytes) and its physical location (i.e., the addresses of the blocks of storage containing the fileβs data on a HDD), (2) the fileβs owner and group, (3) the fileβs access permissions (i.e., which users are permitted to read, write and/or execute the file), (4) timestamps telling when the inode was created, last modified and last accessed and (5) a reference count telling how many hard links point to the inode.
Because most web servers are Linux-based, inode management is going to be important. You can think of them like they are links to your website. You can have multiple links pointing to the same page of your site, but that doesnβt mean there are multiple copies of that page. The same is true of files and inodes.
While technically, there is not a 1:1 relationship, youΒ will find many instances where there is only 1 file linked to 1 inode. Most users can work under the idea they are.
The Problem with Inodes
They run out. They are finite. And you probably arenβt tracking your inode usage.
Not too long ago, I received the βWarning: Account YourSite.com Reached 80% Of The Allowed Inode Quotaβ emailΒ from Siteground out of the blue. I hadnβt done anything out of the ordinary, but somehow, I was stacking up my inodes like a tower. I would guess that if youβre running multiple installations of WordPress on your hosting account, you have gotten (or will get) a similar email.
Now, in the email, theyβre very straightforward: To decrease the number of inodes, you need to reduce the number of files and folders on your account via cPanel β File Manager or your preferred FTP client. And in essence, thatβs all you have to do. But itβs a bit more complicated than that because if youβve had your host for any amount of time, youβve probably got a pretty decent archive of files and folders in there.
To check your inode usage, you will want to log into your cPanel and look for theΒ Stats box. In most versions of cPanel, it will be to the left of the page somewhere. You will see primarily theΒ Disk Usage Space in MB and GB, as well as the number of inodes youβre allowed and the number of inodes youβre using at that moment.
Luckily, like most things about WordPress, the CMS is put together in a way that makes managing your inodes relatively straightforward.
Why Inodes Matter for WordPress Users
Many of you may never have to work with inodes. In day-to-day business, you wonβt really notice them at all. As long as everything is going well with your site, nothing should make you ever even see the word. Itβs when something goes wrong that you will start seeing errors in your WordPress dashboard or somewhere else.
Generally, every hosting provider out there who uses cPanel (which is most of them, unless youβre going for managed hosting) has allotted you a certain number of inodes based on your package. The rule is generally the more you pay, the more inodes you get.
Keep in mind that this is entirely separate from how much storage space you have. The two may be 1:1-ish in volume, but you will generally run out of inodes before you run out of storage space because inodes are a lot smaller in terms of bits and bytes than most of your files (because theyβre only part of the file itself).
That said, WordPress users often find themselves fighting some inode-centric issues.
How WordPress Users Build Up Inodes
While every CMS out there has its own unique ways of taking up inodes, WordPress has some that are specific to its ecosystem. Primarily images, plugins, and themes. Letβs dig in and find out why and what we can do about it.
Images
Images in your media library likely take up a ton of your inodes. Even if you donβt have thousands and thousands of them. I would wager that most of you upload images to your site. And in theory, 1 image equals 1 inode. But thatβs not how things actually work. Depending on your theme and your image compression plugin, that 1 image can take nearly a dozen inodes. How? By keeping renders of multiple sizes in storage.
If you check the details of any image in your library and see a file size, then itβs an inode. Think about that for each and every image in your media library. For this one particular site, I have 562 items in the media library. Assuming (probably incorrectly) that they each have 11 versions, thatβs 6,000+ inodes. Literally eleven times what it should be.
And thatβs for one site. If you take into account the number of sites on any general hosting plan, that number can really add up. On my own account, I have a dozen installations of WordPress running. On top of the Core files from each install, the media libraries from all the users increaseΒ inode usage.
Plugins and Themes
You have a few reasons that plugins and themes take up so many inodes. The first is simply that many people have tons of them installed, even if theyβre deactivated.
And within each of these plugin folders, dozens and dozens of files are taking up inodes. Some plugins are obviously lighter than others, but all of them add bulk to your installation. So remember that itβs generally best practice to delete any plugins that you arenβt currently using.
Themes work the exact same way. Thereβs no telling how many themes you have installed on your WordPress site if youβve had it for a decent amount of time. Even if those themes are simply the default WordPress themes, you have a lot of inodes being used. If youβre not using a theme, delete it. If youβve made customizations via a child theme, however, itβs generally okay to keep it there (or make a backup) since you canβt just reinstall it as easily as you can the parent theme.
Caching Plugins and Backup Utilities
Comet Cache. WPRocket. Updraft. iThemes. WordFence. WP Super Cache. W3 Total Cache. Sucuri.
All of these (and more) take up precious inodes. For the most part, thatβs okay. Theyβre amazing security and caching plugins that make your life easier and your usersβ experiences on your site better. But left unchecked, however, the cache files and backup files and security reports can build up.
So every once in a while, make sure that you clear the cache on your site and let it repopulate itself. Most of the time, you can find aΒ Purge Cache orΒ Delete Cache button in the admin toolbar.
Additionally, extra backups from plugins like UpdraftPlus can take up precious space. So check to see what you have stored on your local server. You can do this from within your WP admin panel for most backup utilities. Or you can check via FTP.
On top of these backups taking up inodes and storage space on your server, theyβre also vulnerable to hackers who may get into your installation. So keeping them in a remote destination (Dropbox or Google Drive, for example) is going to be the best idea.
How to Fix Common Inode Errors
And even though WordPress has platform-specific inode issues, there are some that are common across the web. Whether youβre on Drupal,Β Joomla, WordPress, or even Ghost, you may have to fix these at some point.
- Emails wonβt send, either through a traditional client, viaΒ autoresponders, or from forms on the site itself
- Canβt receive emails
- Uploads consistently fail
- Posts and Pages wonβt update or even create
- Users cannot access the site
- In some cases, migration from one host to another might be blocked
In all of these cases, what might be the culprit is that the server is approaching the top end of its inode quota. Or that itβs completely out of inodes. Remember, even if youβre using only a portion of your storage capacity, you can still use up your inodes.
Every time an email is sent or received, a file is generated. If there are no inodes, no file can be made. If your inodes are full, uploads will fail because there is simply nowhere to store the data. The same can be said for posts and pages in WordPress or other CMS platforms canβt generate the necessary files without a spot. Even when users visit the page, files are generated β cookies, tokens, cached files. If thereβs no inode, those users get nothing served to them.
When migrating from one host to another, your inode allotment may be different. Mine was the last time I swapped, personally. So you may not even be near your current quota, be already be over your upcoming one. It may sound like a pain, but it was really easy to fix, actually.
Here are the best ways to remove files and free up some space to fix these common inode errors.
Delete Old Emails
You see, every time an email is sent or received, it creates a file on your server (assuming that youβre not using an external mail service). That means all your mail is taking up inodes. If you archive or simply hold your emails in your inbox, those are sitting on your server, stagnating. So itβs time to delete them. You can do this in your normal client, or you can do it via FTP or through your cPanelβs File Manager.
Simply go into the root directory of your site and find theΒ Mail folder. Under it will be directories for each domain you have an email address for, and under each of those will be any of the aliases youβve set up. Each one of those folders is important and can be full of inode-stealing files. You will be primarily concerned with theΒ cur andΒ new directories, though. SometimesΒ Junk.
After just deleting the new emails in this one address, I went fromΒ 218316 inodes used toΒ 218218. You should have an even greater gain because this email address was very rarely used in the first place.Β Just remember to back up all the emails before you delete them. You canβt get them back otherwise.
Clear Your Temp Folders
Temporary files are fantastic beasts. If you know where to find them, you can make sure that they are doing their jobs, but not taking up far too many resources. Whenever you see aΒ tmp directory, this is where those temporary files are stored. Session tokens, cache files, traffic logs, all sorts of stuff that are great at the time, but serve no purpose later.
Unless youβve set up an automation or CRON job to clear out temporary files, you may need to go in every once in a while and perform a little housekeeping. Primarily these will be in your root directory underΒ tmp.
As a general rule of thumb, you can delete any log files, cache files, or session files. For the most part, you will see them noted very clearly. Usually the file name will containΒ sess orΒ cache orΒ log, making your job very easy.
Most of the files you delete will be server logs and traffic logs. As long as you have a backup of these files, go through yourΒ tmp folders and delete what you need to. In this particular example, I am clearing out the webalizer, webalizerftp, horde, awstats, andΒ analog directories.Β Please keep in mind that removing these files will remove server statistics and logs, so back them up first if necessary.
You can check the dates on them, too. Depending on your site, you may not need logs all the way back to 2011.
Additionally, you will find a handful of files in your primaryΒ tmp folder, too. They might be a mix of session files, log files, and other files that youβre not sure about. Just like everything with computers and web development, if you donβt know what it is, leave it alone. But it is very important that you do not delete any files that have a .sock extension. And to a lesser extent, .lock.
Clear Your Log Files
Similar to theΒ tmp folder, theΒ logs folder is a root directory that contains archive upon archive of your serverβs logs. Your server begins keeping a log for each domain for each month youβve had it active on your host. That can be aΒ lot of logs. Make a backup of them because theyβre kind of important and delete away.
Delete Unnecessary Website Installations
There are two reasons that you donβt want to have superfluous installations taking up your inodes. The first is, well, youβre wasting inodes on something that youβre not using. The second is that forgotten websites are vulnerable to major security threats and are the most common way for hackers to get into shared servers viaΒ brute force attacks.
Remember how I said earlier there were 12 installations of WP on my personal hosting plan? Well, 8 of those 12 are completely (or at least mostly) useless. Of those, 6 can be deleted without worry and 2 are placeholders.
There are over 5,000 files in each WordPress installation β which is at least 5,000 inodes β and if you did anything to customize it or add plugins or themesβ¦well, you and I should both probably take a look at what we have sitting around on our server.
Wrapping Up
Running out of inodes on your host is annoying and disruptive. Even if you get warned long before you reach capacity, you still have to take a good amount of time to clear out data from your server. However, if you take a quick pass through all of the tips above, you should be able to easily lower inode usage by at least 20% in one pass.
Whether youβre on WordPress or some other CMS, inode usage is something that may not come up very often, but when it does, youβll be very glad that youβre ready for it.
What have you found is the best way to lower inode usage on your sites?
Article featured image by strangebirdy / shutterstock.com
Very useful article!
This is a great walkthrough, thanks.
What about SSL Certificates? In my file system, I have a bunch of files in /ssl/certs/ and /ssl/keys/, some are over a year old.
So in other words inode is a fancy word for “file count”
If you have “inode issues” (technically, they are vnodes in modern OS’s, but we’ll let that one slide) then change service providers. In the “olde days,” the number of inodes on a filesystem was fixed. In modern systems, vnodes (which translates to virtual index nodes where inodes are index nodes) can be expanded almost as much as the filesystem could handle. Any service provider limiting you on inodes, or the number of files, has problems. Either they are using it to suck more money from you (see GoDaddy) or they are incompetent (see everyone else).
Thanks for this well-crafted, helpful article!
What a terrific tutorial !
As a GoDaddy client, we have been held hostage with capacity issues. No one could explain to us what was happening, but they wanted more money. Shock!
Emails kept blipping….etc.
This was an intelligent explanation that GoDaddy staff needs to understand. Ugh!
We will now look at the German company. GoDaddy, after 20 years, needs to be replaced.
Thanks everyone for a quality conversation and heads up.
Nice – would love to see a sample script that could be run on chron to clean up the areas where extra files gather.
Wow..haven’t heard of this before but when someone gets a warning about their site size now I know all the things I should check. Most of the general things I do already but the hidden stuff is what I need to look at. Thanks
Thanks BJ, interesting article, I have also done cleaning.
I would recommend for anyone considering to learn Linux, a VPS.
For those who may be interested in the data, my hosting is DigitalOcean, 25GB HD, 5US$/mo. The limit of Inodes is not 300,000 but 1,632,000:
~$ df -i
Filesystem Inodes IUsed IFree IUse% Mounted on
udev 124545 377 124168 1% /dev
tmpfs 127000 1009 125991 1% /run
/dev/vda1 1632000 262571 1369429 17% /
tmpfs 127000 1 126999 1% /dev/shm
tmpfs 127000 4 126996 1% /run/lock
tmpfs 127000 16 126984 1% /sys/fs/cgroup
tmpfs 127000 4 126996 1% /run/user/1000
~$ df
Filesystem 1K-blocks Used Available Use% Mounted on
udev 498180 0 498180 0% /dev
tmpfs 101600 3020 98580 3% /run
/dev/vda1 25671528 10086312 14319716 42% /
tmpfs 508000 0 508000 0% /dev/shm
tmpfs 5120 0 5120 0% /run/lock
tmpfs 508000 0 508000 0% /sys/fs/cgroup
tmpfs 101600 0 101600 0% /run/user/1000
tmpfs 101600 0 101600 0% /run/user/0
Oh yeah, absolutely. If you know Linux and the command line, managing inodes is pretty smooth. I actually chose not to include them here because I didn’t want to intimidate folks who were new to the topic. But you’re totally right. If you can dig in on the command line, it gives you a lot of information to work with.
I have send a link of this article to my US hoster and they write back:
Hello,
You should not need to worry about inodes on the account as we don’t have a restrictions on inodes. Your account can use as many as needed, as long as it is a reasonable amount. If you are using wordpress, you should have no issue.
Regards,
Walben Whitebrew
WebHostingPad Support
This, of course, is the right answer. If you get any other answer, find a new hosting company.
BTW: I use 1&1 (or whatever they are calling themselves these days). I have had no problems with inodes or space!
DCDawg, See my reply to Oliver Gehrmann above (the 2nd post in this blog).
I started with 1&1 in 2003, and have built dozens of websites using them as the host for many clients… but the s**t hit the fan a few months ago.
Which host is this?
That’s excellent news! Good for them!
Those suggesting providers are screwing their customers by limiting inodes are misled. Inodes are a filesystem resource with a hard limit, just like blocks. To say it is reasonable to limit the number of blocks (disk space) I can use, but it is not reasonable to limit the number of inodes, is nonsense. Both are limited resources. Why is it reasonable to allow a user with 10% of the disk space to consume 50% of the inodes?
Great info B.J.
I have two dedicated servers and inodes can be a problem because as a customer service, I run full daily backups on all of our sites.
If the number of inodes or files is huge then the backups take way too long to run, which is why I worry about how many there are per site.
Our system starts flagging at around 250,000 and then starts skipping the backup for any site that goes over 300,000 with a warning to the client to get the number reduced so backups can continue to be run on their site.
That said, I have only ever had one site that went over the top, out of thousands of sites, so its not a huge concern for most clients.
This article makes it seem like this is an issue for all WordPress users. It isn’t.
It is only a problem for users who rent server space from hosting companies that don’t provide decent service. I don’t have those limits. In fact, the majority of people who read this article won’t see the “inode” listing in their Cpanel at all.
On the contrary, it is a limit imposed by most hosting providers. I am a web developer and I have had clients with different hosting providers including Hostgator, BlueHost, DreamHost, Flywheel, InMotionHosting, FatCow, and SiteGround, among others. Some of these are bad providers, but some are good too. And the good ones like SiteGround too have inode limits, even if it is not explicitly mentioned in the plans’ description.
One just needs to have a pre-sale chat with their support team and ask about the inodes limit.
+1
I use Siteground and I have to deal the problem of inode, when I worked on a site every day for changes.
But I always prefer Siteg. to others.
This is very good information. I had NEVER heard of inodes before this. That means I’ve never had a problem with them, either. Of course, I have only been building websites since 1995, so maybe I don’t have enough experience yet (Grin!). Maybe I’ve just been lucky so far. At least now I have some information for that day when I might run into the issue.
This is, in my experience, an exclusively American problem and it is a great example how US providers are screwing over their customers.
I’m running 40+ websites (all WordPress installations) on a shared hosting account (! – it’s not some super expensive web hosting plan… it’s SHARED HOSTING, the “cheapest option”) and I’ve yet to run into any problems with inodes. At the same time, one of my clients was using GoDaddy as a hosting provider and he was running into problems with ONE installation of WordPress.
It is a complete rip off what US providers are doing to their customers. You get more bang for your buck with almost ANY German hosting provider, even the “bad ones”. I got a list of providers and all of the US providers I worked with – even the ones with “stellar reputation” – tend to clock in towards the end of that list.
Oliver, I have several of my own websites, and over a dozen of my clients’ websites, hosted by 1&1 (recently merged to become 1&1 IONOS)β¦ a VERY GERMAN company.
All was well until a few months ago when one of my client’s websites would not allow any more blog additions, and then I realized, no more editing either. I received no warning at all. I called the 24/7 customer service tech team and learned all about “inodes” for the first time (although not by that technical term). Apparently the website had hit a brick wall at 262,144 files, even though the “unlimited storage” available was always the only thing the host advertised. After a frantic attempt at deleting files, as I was advised to do by the service tech, I realized that I had recently installed a caching plugin, and that it practically doubled the number of files, bringing me right up to the brick wall. I deleted it and cleaned out all it’s files, and suddenly was down to around 150,000 files, and everything was good again.
No warning was the main issue I have with this host, but I have too much time, learning and client accounts invested to start looking for a better host.
I found this article VERY educational and helpful for the future.
Great information, B.J.! Thank you!