Linux Inodes: File Metadata, Inode Numbers, and Disk Limits

Learn what Linux inodes store, how filenames and hard links use inode numbers, how to inspect them, and why inode exhaustion can occur with free disk space.

An inode is a filesystem data structure that represents a file or another filesystem object, such as a directory. Each inode has a unique integer identifier called an inode number within its filesystem. The filesystem assigns an inode when an object is created.

Inodes are central to understanding Linux file metadata, hard links, directory entries, and a particular kind of storage problem: a filesystem can run out of inodes even while it still has unused disk capacity.

What an inode stores

Metadata is descriptive information about a file rather than the file's contents. An inode stores metadata and references that help the filesystem locate the contents.

File type: whether the object is a regular file, directory, symbolic link, device, or another filesystem object.
Permissions: access mode bits, including read, write, and execute permissions for the owner, group, and others.
Owner user identity: the user ID associated with the object.
Owner group identity: the group ID associated with the object.
File size: the logical length of the file.
Link count: the number of directory entries that refer to the inode.
Timestamps: time information such as modification, status-change, and access timestamps where supported and applicable.
Data references: pointers or other filesystem references used to locate the file's data blocks.

Item	Stored in inode?	Explanation
File type	Yes	Identifies the kind of filesystem object.
Permissions	Yes	Stores the access mode, including read, write, and execute permissions.
Owner and group	Yes	Stores user and group identities associated with the object.
File size	Yes	Records the logical size of the file.
Link count	Yes	Counts directory entries that refer to the inode.
Timestamps	Yes	Records applicable filesystem timestamps.
Locations or references to file data	Yes	Provides references the filesystem uses to find data blocks.
Filename	No	The filename is stored in a directory entry that maps the name to an inode number.
File content	No	The contents are stored separately in data blocks or equivalent filesystem structures.

What an inode does not store

The inode does not directly contain the file's contents. It contains references that allow the filesystem to locate those contents.

The inode also does not contain the filename. A directory entry is a directory mapping that associates a filename with an inode number. This separation explains why one inode can be associated with more than one name.

Viewing inode numbers

Use ls -il to display a long listing that includes the inode number:

ls -il /path/to/file

The -i option requests the inode number, and -l requests long-format metadata. The inode number is the leftmost field in the output. The remaining fields commonly show permissions, link count, owner, group, size, timestamp, and filename.

$ ls -il /path/to/file
123456 -rw-r--r-- 1 alice developers 2048 Jun 10 09:30 /path/to/file

In this illustrative output, 123456 is the inode number. The value is meaningful only within the filesystem containing the path. Two files on different filesystems can have the same inode number without referring to the same object.

For a shorter listing, use:

ls -i /path/to/file

For more detailed metadata, use:

stat /path/to/file

The stat output typically includes the inode number and link count along with permissions, ownership, size, and timestamps.

Directories, filenames, and inode numbers

A directory can be understood as a collection of mappings from names to inode numbers. When a program opens a path, the filesystem resolves each directory component, finds the directory entry for the final name, and obtains the inode associated with that name.

Renaming a file generally changes a directory entry: the old name is removed and the new name is added. The underlying inode usually remains the same. Therefore, a rename normally does not create a new inode or copy the file's contents.

ls -i report.txt
mv report.txt final-report.txt
ls -i final-report.txt

When both commands refer to the same filesystem object before and after the rename, the inode number normally remains unchanged.

Hard links and link counts

A hard link is an additional directory entry that refers to the same inode as another filename. The two names are different directory entries, but they identify the same underlying file data and metadata.

touch original
ln original alias
ls -il original alias

The two listing lines should show the same inode number when both names are on the same filesystem. Their link count should indicate that two directory entries refer to the inode.

Because both names refer to one inode, changing the contents through either name changes the same file. Changing metadata, such as permissions, also affects the shared inode.

Removing one filename removes one directory entry and decreases the link count. The data remains available through the other name. The filesystem normally releases the inode and data only after the final hard link is removed and no process still has the file open.

Filesystem inode allocation

How inodes are created and made available depends on the filesystem and its version and configuration. Allocation behavior should not be assumed to be identical across all filesystems.

Filesystem example	General inode allocation approach	Operational implication
ext3	Inode capacity is commonly established when the filesystem is created.	The selected inode density can affect how many files the filesystem can hold; changing it later may require recreation or migration.
XFS	Inodes can be allocated dynamically or as needed within the filesystem's allocation structures.	Inode availability behaves differently from a simple fixed-at-creation model, but filesystem-specific limits and configuration still apply.

This comparison is general. Always consider the actual filesystem type, implementation, version, and configuration before planning capacity.

Inode exhaustion

Inode exhaustion occurs when a filesystem has no available inodes for new filesystem objects. It can happen even when the filesystem still has free data blocks or free storage capacity.

Every file usually requires an inode, regardless of whether the file is large or small. A workload that creates millions of small files can therefore exhaust inodes while consuming less data space than a smaller number of large files.

Common causes include:

Application caches containing many small files.
Temporary files that are not removed.
Large mail queues or spool directories.
Build artifacts and dependency trees.
Log-processing or download jobs that create many fragments.
Directories containing very large populations of generated files.

Check data-space capacity and inode capacity separately:

df -h
df -i

Resource	What it limits	Primary check command	Typical symptom when exhausted
Data blocks or disk space	The storage available for file contents and filesystem structures.	`df -h`	Writes or file growth fail because ordinary storage capacity is full.
Inodes	The number of filesystem objects that can be represented.	`df -i`	New files or directories cannot be created even though `df -h` shows free space.

The df -i output reports inode totals, used inodes, available inodes, and inode-use percentage for mounted filesystems. A filesystem near or at 100 percent inode use can explain a “no space left” error when ordinary disk-space output appears healthy.

Finding directories with many files

To count regular files below a directory without crossing into another filesystem, use:

find /path/to/directory -xdev -type f | wc -l

This is an illustrative count. Traversing a very large directory tree can take time and may itself place load on the system. Run it with an appropriate path and permissions, and investigate application-specific directories such as caches, temporary locations, queues, and build output.

Troubleshooting inode-related problems

“No space” despite free disk space

Run df -h to check ordinary data-space usage.
Run df -i to check inode usage and available inode counts.
Identify directories containing unusually large numbers of small files.
Remove unneeded caches, temporary files, logs, queues, or build artifacts according to the application's retention rules.
If cleanup is insufficient, plan a filesystem migration, recreation, or resize strategy appropriate to the filesystem's inode capabilities.

Do not delete files blindly from system or application directories. Confirm ownership, purpose, retention requirements, and whether a service needs to be stopped before cleanup.

Two names have the same inode number

Use:

ls -il file-a file-b

If both paths are on the same filesystem and show the same inode number, they may be hard links. Compare their link counts and inspect them with stat. Treat changes through either name as changes to the same underlying data.

A rename leaves the inode number unchanged

This is normally expected. A rename changes the filename-to-inode directory mapping rather than creating a new file. Use ls -i before and after the operation to observe the distinction between a filename and the inode representing the file.

Exam-relevant summary

An inode is a filesystem record for a file or related filesystem object.
An inode number identifies that inode within one filesystem.
Inodes store metadata such as type, permissions, ownership, size, link count, timestamps, and references to data.
Inodes do not directly store the filename or file contents.
Directories map filenames to inode numbers.
A rename usually changes a directory entry, not the inode.
Hard links are multiple directory entries pointing to one inode.
The link count decreases when a hard-link name is removed.
ls -il displays the inode number as the leftmost field.
df -h checks data-space usage, while df -i checks inode usage.
Many small files can exhaust inodes even when data-space capacity remains.