VMware ESXi and vSphere Cluster Management

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

Learn what Linux inodes store, how filenames map to inode numbers, how hard and symbolic links differ, and how to diagnose inode exhaustion.

An inode is a filesystem metadata record that describes a filesystem object. Files, directories, symbolic links, device files, sockets, and FIFOs can each have an inode.

Every inode has an inode number, a numeric identifier that is unique within its own filesystem. The number identifies the underlying object, not a pathname. A pathname is a route through directories that leads to an object.

Inodes are managed by the filesystem, the formatted storage structure that organizes directories, files, metadata, and data allocation. Inode numbers and inode availability are therefore specific to each mounted filesystem.

What an inode stores

An inode stores descriptive information called metadata. Metadata tells the operating system what an object is, who owns it, how it may be accessed, how large it is, and where its contents are stored.

AttributeStored in inode?Where it is represented
PermissionsYesPermission bits and access mode in the inode
Owner and groupYesUser and group identifiers in the inode
File sizeYesSize metadata in the inode
TimestampsYesAccess, modification, and metadata-change times
File typeYesType information such as regular file, directory, or symbolic link
Link countYesNumber of directory entries referring to the inode
Data location referencesYesReferences to data blocks or extents
FilenameNoA directory entry maps the name to an inode number
File contentsNoData blocks or extents hold the contents

An extent is a contiguous range of storage blocks. Modern filesystems can use extents to describe large regions of file data efficiently. An inode may contain direct references to storage or references to structures that describe the file's blocks or extents.

Filenames, directory entries, and file identity

A filename is not normally stored as part of the inode's metadata. Instead, a directory contains a directory entry: a record that associates a name with an inode number.

For example, a directory entry might conceptually contain:

report.txt  ->  inode 48192

The inode then describes the object and points toward the storage containing its contents. This separation explains why one underlying object can be reached by more than one pathname.

Two names may refer to the same inode. Conversely, two names that look similar may refer to different inodes. An inode number is useful for checking this relationship, but compare it only within the same mounted filesystem. The same numeric inode value on two different filesystems does not prove that the objects are the same.

Viewing inode numbers and metadata

Using ls

Use ls -i to display inode numbers for directory entries:

ls -i

Use ls -il to combine inode display with long-format metadata:

ls -il filename

In long-format output, the inode number appears at the beginning of the line. The link count appears after the permission and file-type field.

48192 -rw-r--r-- 2 alice developers 2048 Aug 18 10:30 filename

In this example, 48192 is the inode number and 2 is the link count. The exact columns and spacing can vary with the command implementation and options.

Using stat

stat displays detailed information about one filesystem object:

stat filename

Typical output includes the inode number, permissions, file type, owner, group, size, link count, and timestamps. It is often easier to read than a long directory listing when investigating one object.

Finding entries by inode number

Use find with -inum to search for directory entries with a particular inode number:

find /path -inum INODE_NUMBER

The search is limited to the filesystem content reachable under the specified path. If the path crosses mount points, use appropriate find options when you need to keep the search within one filesystem.

Hard links and inode link counts

A hard link is an additional directory entry that points to the same inode as an existing name. It is not a second copy of the file's contents.

printf '%s\n' 'shared content' > original
ln original hardlink-name
ls -il original hardlink-name

The two names should show the same inode number. Their link count should also show that multiple directory entries refer to the inode.

When a hard link is created, the inode's link count increases. Removing one name decreases the count, but the inode and its data remain available while at least one directory entry still refers to it. Therefore, removing one filename does not necessarily remove the underlying file data.

Hard links normally must be created within the same filesystem. A directory entry on one filesystem cannot be a hard link to an inode on another filesystem. Hard links to directories are generally restricted because they could create directory cycles; ordinary hard-link demonstrations use regular files.

CharacteristicHard linkSymbolic link
Inode relationshipAnother directory entry for the target inodeA separate filesystem object with its own inode
Cross-filesystem behaviorNormally cannot cross filesystem boundariesCan refer to a path on another filesystem
Directory-link behaviorOrdinary users generally cannot create hard links to directoriesCan point to a directory path
Behavior when target name is removedData remains accessible through the other hard-link namesThe link can become dangling because its stored path may no longer resolve
Typical creation commandln original hardlink-nameln -s target symlink-name

Symbolic links compared with hard links

A symbolic link, or symlink, is a separate filesystem object. Its contents are a target pathname, such as /var/log/application.log or a relative path. The symlink has its own inode; it is not another directory entry for the target's inode.

printf '%s\n' 'target content' > target
ln -s target symlink-name
ls -il target symlink-name
ls -ilL symlink-name

Without -L, the first listing examines the symlink itself. The symlink and target should have different inode numbers. With -L, ls follows the symlink and reports the target object instead.

A symlink can stop working if its target is moved or removed, because the stored target path no longer identifies the intended object. A hard link does not depend on the target's pathname after it has been created.

Inode capacity and inode exhaustion

Creating a file requires both free data space and an available inode. The data space stores contents, while the inode stores metadata and references to those contents. A filesystem can therefore have free bytes but no available inodes.

Inode exhaustion is the condition in which a filesystem cannot create more filesystem objects because its available inode supply has been consumed. This commonly occurs when a system contains very large numbers of small files.

Some filesystems reserve or determine much of their inode capacity when the filesystem is created. ext3 is commonly associated with this model: the inode capacity selected during filesystem creation can limit how many objects it can contain. XFS uses dynamic inode allocation behavior, allowing inode metadata to be allocated as needed within filesystem resource limits. Dynamic allocation does not mean that inode-related resources are unlimited.

Checking inode usage

Use df -i to report inode usage for mounted filesystems:

df -i

Interpret the output separately from ordinary byte-based disk usage. The columns commonly represent total inodes, used inodes, available inodes, and the percentage used. A filesystem may report substantial free space in bytes while reporting zero available inodes.

ConditionBytes availableInodes availableLikely symptomPrimary diagnostic command
Disk-space exhaustionLow or zeroMay still be availableWrites fail because data blocks cannot be allocateddf
Inode exhaustionMay be substantialLow or zeroNew files or directories fail, often with “No space left on device”df -i

Diagnosing inode pressure

When a program reports “No space left on device” but byte-based df output shows free space, check inode usage first:

df -i

If one mounted filesystem is near 100 percent inode use, inspect directories that commonly contain many small objects. Typical sources include caches, mail queues, log rotation output, temporary data, session files, package-management data, and application-generated queue or job files.

Count and inspect files carefully before deleting anything. A useful investigation can start by comparing directory contents and locating unusually large collections of small files. Remove or consolidate data only when it is known to be safe, then run df -i again to confirm that available inode counts increased.

Operational details when deleting files

Deleting a directory entry removes a name-to-inode association. If that was the last hard link and no process has the file open, the filesystem can release the inode and data blocks.

If a running process still has an open file descriptor for the deleted file, the pathname disappears but the process can continue using the inode and its data. Space may not be returned until the process closes the descriptor, often by exiting or restarting. Other hard links can also keep the inode and data alive.

Practical comparison: one inode versus separate inodes

Hard-link example

printf '%s\n' 'data' > original
ln original hardlink-name
stat original
stat hardlink-name
ls -il original hardlink-name

original and hardlink-name should have the same inode number and a shared link count. Editing either name changes the same underlying file.

Symbolic-link example

ln -s original symlink-name
ls -il original symlink-name
stat symlink-name
stat -L symlink-name

The symlink itself has a different inode from original. Plain stat describes the symlink, while stat -L follows it and describes the target.

Key points

  • An inode is a metadata record for a filesystem object.
  • It stores type, permissions, ownership, size, link count, timestamps, and references to file data.
  • A directory entry stores a filename-to-inode-number mapping.
  • File contents live in data blocks or extents, not normally inside the inode.
  • Inode numbers identify objects only within their own filesystem.
  • Hard links share one inode; symbolic links have their own inode and store a target path.
  • ls -i, ls -il, stat, and find -inum help inspect inode identity.
  • df -i diagnoses inode capacity separately from byte-based disk usage.
  • Many small files can exhaust inodes even when a filesystem still has free data space.
  • A deleted pathname may not release storage while other hard links or open file descriptors remain.

For a focused reference, see Linux inode concepts.