In inode-based Unix filesystems, a directory maps each entry name to an inode number. The inode represents the filesystem object and records metadata needed to find and interpret its data. The pathname is therefore not stored as the object's own primary identity.
The Filesystem · Lesson 11
Inodes
Learn how inode numbers connect directory names to filesystem object metadata and data.
Metadata Stored with an Inode
Common inode-associated metadata includes:
- object type and permission mode
- user and group ownership
- logical size and allocated-block accounting
- hard-link count
- access, modification, and status-change timestamps
- references to file data or filesystem-specific extent structures
The inode does not normally store the directory-entry name. A filesystem may also store extended attributes, access control lists, birth time, inline data, or other information through format-specific structures.
ctime is the inode status-change time, not necessarily file creation time. A separate birth or creation timestamp is optional and may be unavailable.
Where is a regular file's pathname component normally associated with its inode number?
Inode Numbers and Filesystem Scope
Display inode numbers with:
$ ls -li
The first field is the inode number. Inspect one object in more detail with:
$ stat path
An inode number is unique only within one filesystem at a given time. The same number can exist on another filesystem, and a number can be reused after an inode is freed. Identify an object robustly with both filesystem identity and inode number rather than inode number alone.
Within what scope is an inode number an object identifier?
Hard Links and Open References
Several directory entries can refer to the same inode; these are hard links. Creating another hard link increments the object's link count. Removing one name decrements the count without deleting the data while another link remains.
Even after the final directory entry is removed, an open file remains allocated until the last process reference closes. Its link count can be zero while a file descriptor still accesses it. This explains why deleting a large open log might not immediately reduce df usage.
When are an unlinked file's resources normally released?
Inode Capacity
On filesystems with a finite or reported inode pool, millions of small files can exhaust metadata capacity before data blocks fill. Inspect mounted filesystem inode accounting with:
$ df -i
If no free inodes remain, creating another file can fail even when df -h reports available blocks. Allocation strategies differ: some filesystems preallocate inode structures at creation, while others manage metadata dynamically and may report inode capacity differently.
What does df -i report where the filesystem provides inode accounting?
Filesystem-Specific Data Mapping
Do not assume every inode has exactly 12 direct pointers plus three indirect pointers. That is a useful description of some classic filesystem layouts, but modern ext4 can use extents, and XFS, Btrfs, and other filesystems use different structures. Inline data and compressed or copy-on-write extents further change the relationship.
Use filesystem-specific diagnostic tools only in read-only or documented modes when internal mapping matters. For ordinary administration, stat, find -inum, df -i, and link-aware tools provide safer abstractions.
Why should you not assume one fixed pointer layout for every inode?
Use Manage Files and Directories in Linux to compare inode numbers and link counts on disposable files.
Lesson complete
You finished Inodes
You can now relate pathnames, inodes, links, and filesystem capacity.
Treat directory entries as mappings from names to inode numbers.
Read metadata and timestamps without confusing ctime with creation.
Scope inode numbers to one filesystem and moment.
Account for both hard links and open file descriptors.
Use filesystem-specific models rather than one universal pointer layout.
Keep your learning progress
Create a free account to save this lesson and continue learning on any device.
Create a free account