Idea: Clear unnesesary inodes feature

Usually php scripts have tests folder and scripts in this folder is not used. Shall we put an option to remove such files in account in order to free inodes?

According to this idea, there are 2824 unnesesary inodes used in my hosting.

In total of 27250 inodes.


There are might be other unused files too.


yeah it will be impossible to determine which files/directories are dead and which are active


./vendor/*/tests files shouldn’t be a problem IMO.

Also, I’m not suggesting this be forced/automatic. It’s the user’s choice to use it, and it’s the user’s responsibility to make sure it doesn’t break anything.

1 Like

For most Composer-installed libraries, it won’t be. But I can imagine that there may be, say, a validation library here that has a set of “test” functions/classes/files that will break if you run this find expression on it.

That does require properly informing the user about what’s going to be deleted before actually deleting it. And for the user to properly understand the consequences.

I will guarantee you that if you offer a function to “delete unnecessary files”, a lot of people will just think “hey, that’s useful, I just click this link, and then click next, next, next, next and then my inode usage will go down, and it’s just unnecessary files and the hosting wouldn’t break my site, wouldn’t it?”.

If you offer this functionality, I know for certain that many people will not pay attention to what’s being deleted, will delete files that are very much still necessary, and then get angry at us for breaking their site.

And “just inform them properly” doesn’t work. Experience has shown time and time again that many people simply don’t read and just go by their own hopes and assumptions in spite of all the information you shove in their face to contradict it.

Give people a gun and they will shoot themselves in the foot with it. And a tool that starts deleting files from their account is a very big gun.


Maybe adding a “rollback” feature is useful too. So, “delete unnecessary files” button will be 3 pages. 1) Inform user 2) Hide/Move files 3) Wait user action for rollback for X hours, delete else.

Anyway I agree with you, there’s no proper way to find those unnecessary files → big risk.


That’s making an already complicated feature a lot more complicated. Now the feature will need to:

  • Map out the directory structure of the account.
  • Find all the directories matching a certain pattern.
  • Move or copy the files somewhere, keeping track of which files were moved and where they came from.
  • A system to (automatically or manually) delete the trashed files (keeping track of the fact that there may have been multiple deletion runs).
  • A system to move back the trashed files, keeping in mind that new files may have already been moved into place.

It’s not impossible, but very complicated with file operations, state management and conflict resolution.


And then it all stops because it triggered the IO limit :joy:


My last words.
It’s your server, it’s your decision to add/work on it/abandon it. Mine is just an idea.
I agree it has many minus sides, but if you like to implement it to panel - I’ll do my best to help. @Admin

1 Like

Should I test? :smiley:

1 Like

Whatever you wish + it is your responsiblity to take care of whatever that happens to it.


If I’m going to be building it, most of this should be done through FTP, so no need to worry about IO limits.

I do have some ideas on how it could work in a way that’s probably not completely stupid. But it’s still a complicated beast with a lot of moving parts for something that I think is not that useful for that many people. So don’t get your hopes up.


its an interesting problem to solve, good luck :+1: :+1: :+1: :+1: :+1:


Is there any analysis of which actions fill the most inodes ?

Was it experimenting with Softaculous in the sense that someone doesn’t know what he wants and then installs 5 forums and 10 scripts
and doesn’t wipe off the rest of it?

Or is it that someone tries 30 themes for WP and plugins, which then leaves a bunch of unnecessary files?

Or the third… that someone has file uploading and the like, so, of course, a lot of things accumulate?

I think that before creating such a program, you should collect at least 10 paths
which could be deleted so that it would make sense to invest time in it all

On the other hand, if you know 10+ paths where files can be freely deleted
then it’s better to report it to ifastnet and let them optimize their servers on a monthly basis rather than you doing it for them :slight_smile:

  1. Well, acces time of the files are an option. Ony if drives are not mounted with noatime option.
  2. For composer installed libraries, tests files are an option.
  3. Empty folders and files
  4. .log files
  5. …

My best idea to achieve this is staging. But, to copy a website we need to double the inode usage.

1 Like

Not that I know of. But from gut feeling of what I’ve seen from people asking about it, all the things you listed apply.

Eh, not necessarily. You can just make it so that it’s extensible, start with only a few paths and expand it as necessary. And figure out which common junk files are uploaded. Backups, cache directories and other temporary files are probably good candidates. Indiscriminately nuking every node_modules directory will also do wonders for the accounts that contain them.

Two reasons not to do that.

First of all: false positives can exist. If website software X has path Y that can be safely deleted, a different website may also have a path Y that does contain vital data and will break the website if deleted. And I don’t want to have to tell people “sorry that we broke your website by deleting critical files, we were trying to help you by reducing your inode usage”. That’s why such a tool should be triggered by hand, and tell beforehand what data is going to be deleted so the user can check it. Having rollback functionality is even better.

And second: if I put on my evil corporate hat, then helping people reduce their inode usage is bad for business, because it gives people less reason to upgrade to premium hosting, because they don’t need the higher inode limits as much.


I never thought that way


I don’t think this idea needs to be continued.

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.