Inodes

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.

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.

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.

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.

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.

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.

Use Manage Files and Directories in Linux to compare inode numbers and link counts on disposable files.

Summary

You can now relate pathnames, inodes, links, and filesystem capacity.

1. Treat directory entries as mappings from names to inode numbers.
2. Read metadata and timestamps without confusing ctime with creation.
3. Scope inode numbers to one filesystem and moment.
4. Account for both hard links and open file descriptors.
5. Use filesystem-specific models rather than one universal pointer layout.