An inode in Linux is a file system structure that stores a file's metadata: permissions, owner, timestamps, size, and information about where its data is located. The file's name and its actual content are not stored in the inode. Every file system has a fixed number of inodes, and a server can run out of them even when there's still plenty of free disk space.

This problem comes up especially often when working with directories that have accumulated millions of small files — cache, temporary data, sessions, logs, or queue files. Below, we'll cover what an inode is, how it differs from a file, and how to check inode usage on a server.

What is an inode in simple terms

Think of a file system as an archive. Every file in it has a kind of "passport." The passport records who owns the file, what permissions it has, when it was created and modified, how large it is, and where its data is stored on disk. That "passport" is the inode.

Each inode is assigned a unique inode number within the file system. Using this number, the Linux kernel can locate the corresponding structure and retrieve information about the file.

An inode stores:

  • the file's owner;

  • the owner's group;

  • permissions

  • size;

  • timestamps;

  • the number of hard links;

  • information about the location of the blocks or extents containing the data;

  • various file system attributes.

In ext4, the inode structure contains the file mode, UID/GID, size, timestamps, hard link count, and block information. The file name is not stored in the inode — it lives in the directory entry, which links the name to the inode number. It's technically incorrect to think of an inode as a file, since it's actually a structure that describes a file and helps the file system locate its data.

How an inode differs from a file and a data block

A file can be broken down into three components:

  • Name;

  • inode;

  • data.

The name lives in the directory. The inode holds the metadata and information about where the data is stored. The actual file content sits in the file system's data blocks. For example, take a 5 MB text file — it occupies a certain number of data blocks, while its inode remains a single metadata structure.

This brings up an important point: disk space and the number of available inodes are two separate resources. Imagine a server with 20 GB of free space remaining. If the file system has run out of available inodes, you won't be able to create even one more regular file.

The df -h command will show available space, but creating a new file will still fail with an error:

touch: cannot touch 'newfile': No space left on device

In this situation, check not just the free blocks but the inodes too. A good example is hard links. Multiple names can point to the same inode. Having several names doesn't mean having several independent sets of data. In ext4, directory entries contain names and inode numbers, and multiple entries can reference the same inode.

How to find a file's inode number

You can check a specific file's inode using ls -i:

ls -i example.txt

The result will look like this:

123456 example.txt

The number on the left is the inode number, and the name on the right is the file name.

For a directory, use the same command:

ls -id /var/log

This lets you quickly check the inode of a specific object. On its own, the inode number doesn't tell you how much space a file occupies — it's simply an identifier for the structure associated with a file system object.

How to check inode usage on a server

To check the number of available and used inodes, run:

df -i

The -i flag switches df from showing block usage to showing inode information.

Sample output:

Filesystem       Inodes   IUsed   IFree IUse% Mounted on
/dev/sda1       6553600  420000 6133600    6% /

Here:

  • Inodes — the total number of inodes

  • IUsed — how many inodes are in use;

  • IFree — how many remain free;

  • IUse% — the usage percentage;

  • Mounted on — the file system's mount point.

For comparison, df -h shows disk space usage in bytes/blocks. When troubleshooting disk issues, it's best to run both commands:

df -h
df -i

If df -h shows free space available, but df -i shows nearly 100% inode usage, the error is caused by the sheer number of files.

Can you increase the number of inodes?

It depends on the file system. In ext4, the number of inodes is typically set when the file system is created: it's determined by the formatting parameters, such as a specified inode count or a bytes-per-inode ratio (see man mke2fs).

Simply increasing disk size doesn't guarantee that an already existing ext4 file system will gain enough inodes: when the file system is expanded, the new block groups typically get inodes at the same ratio as before, and changing that ratio usually requires recreating the file system entirely. XFS takes a different approach: inodes are generally allocated dynamically as needed, and their placement parameters are tied to the file system's geometry.

XFS has a parameter called maxpct, which limits the maximum share of file system space that can be allocated to inodes, and it can generally be changed (see man mkfs.xfs and man xfs_growfs). There's no universal advice like "just reformat the disk to get more inodes." You first need to identify the file system type and understand exactly what's limiting its usage.

On Leneex VPS , when running this kind of diagnostics, start by checking the actual state of the file system with df -h, df -i, and, if needed, df -T. If the problem keeps recurring due to the server's configuration, assess after diagnostics whether a different VPS configuration is needed.

What to do if you run out of inodes

If df -i shows close to 100% usage, the task comes down to finding directories where too many files have accumulated.

Common causes include:

  • application cache;

  • PHP sessions;

  • temporary files;

  • large numbers of small log files;

  • mail queues;

  • leftover files from applications;

  • directories with a large number of service objects;

  • application bugs that prevent temporary files from being deleted.

It's best to diagnose the issue step by step.

Find the file system running short on inodes

df -i

First, identify the mount point where IUse% is close to 100%.

Check where the large number of files is located

To find directories with a large number of regular files on a specific file system, use:

find /var -xdev -type f -printf '%h\n' 2>/dev/null |
sort | uniq -c | sort -nr | head -20

This command groups the files found by directory and shows the directories with the highest file counts. For a different file system, replace /var with the corresponding directory.

Figure out what's creating these files

Don't rush to delete the directory you found. First, determine which application uses it. A large number of files in /var/cache/ and the same number of files in an application directory are entirely different situations. In the first case, it might just be normal cache; in the second, it could be an application bug or incorrect data storage configuration.

Only delete what you understand the purpose of

Once you've identified the cause, clean up unnecessary cache, temporary files, or old logs using the application's built-in tools. Don't delete system files blindly. Freeing up inodes at the cost of breaking a running service is a poor way to solve the problem.

Check inode usage again

After cleanup:

df -i

If the number of used inodes has decreased, the problem was indeed caused by an excessive number of files. One more thing worth remembering: deleting a large file doesn't always free up disk space immediately if a running process is still holding it open. That's a separate diagnostic situation that needs to be checked independently.

Summary

An inode is a distinct file system resource that shouldn't be confused with free disk space. A server can have gigabytes of free space available and still refuse to create new files if it has run out of available inodes.

If you encounter a No space left on device error, checking df -h alone isn't enough — check df -i as well, and if inodes are nearly exhausted, look for directories containing large numbers of small files. If these kinds of limitations keep becoming a recurring problem for your project, don't just increase disk size — figure out exactly what's consuming the file system's resources, and only then choose an appropriate VPS configuration.