Inode

The Linux Journal documentation captures the inode definition concisely: “An inode (index node) is a data structure that stores information about a file or a directory, excluding its name or its actual data.” This single sentence captures both what the inode is and what it isn’t; it’s metadata, but specifically the metadata that describes a file rather than identifies it by name or contains its content.¹

The “everything is a file” Unix principle

The Linux Bash inodes documentation captures the underlying philosophy: “In the world of Linux, everything is considered a file, be it a text file, a directory, a device, or even a socket. This universal approach to system resources simplifies interactions but raises questions about how Linux manages this.” Every entity that the file system tracks (regular files, directories, symbolic links, hard links, named pipes, device nodes, sockets) has an inode. The inode is the unifying abstraction that lets Unix treat radically different things (a 4 GB video file and a /dev/null device entry) with the same metadata structure.²

The inode number

Each inode is identified by an inode number (often abbreviated “i-number” or “ino”) that’s unique within its file system. The inode number is the file’s identity at the file system level; tools like ls -i display it, and the stat command shows complete inode contents. Two different files on the same file system always have different inode numbers; the same inode number can exist on different file systems (each file system has its own inode number space) without ambiguity because the file system identity (combined with the inode number) is what produces unique identification system-wide.

Where inodes live on disk

Inodes are stored in inode tables: contiguous arrays of inode structures at fixed locations on the disk. The placement strategy varies by file system:

• ext2/3/4: the volume is divided into block groups, each containing its own inode table. This locality improves performance because related files (in the same directory) are often allocated near each other.
• XFS: uses dynamically-allocated inode chunks rather than fixed tables, allowing the file system to grow without inode exhaustion concerns.
• ZFS / Btrfs: use object-store-style metadata with inode-equivalent records (dnodes in ZFS) that can be allocated anywhere, with no fixed tables at all.
• UFS / FFS (BSD): uses cylinder groups similar to ext2/3, with fixed inode tables per cylinder group.

Inodes are not directories

One common point of confusion: inodes don’t contain directory listings. An inode for a directory is similar in structure to an inode for a regular file; the difference is what the data blocks contain. For a regular file, the data blocks contain the file’s content; for a directory, the data blocks contain a list of (filename, inode-number) pairs that describe the directory’s children. The directory’s structure (how it organizes children) is defined by the data blocks, not the inode; modern file systems use B-trees or hash tables in directory data blocks for fast lookups in large directories.

An inode contains several distinct categories of metadata. The exact format varies between file systems, but the conceptual content is consistent across the Unix family.³

Type and permission bits

The mode field is a 16-bit value encoding both the file type and the permission bits. The high 4 bits identify the file type:

• Regular file: S_IFREG (mode bits indicate regular file)
• Directory: S_IFDIR
• Symbolic link: S_IFLNK
• Character device: S_IFCHR (e.g., terminals, /dev/null)
• Block device: S_IFBLK (e.g., disk devices)
• Named pipe (FIFO): S_IFIFO
• Socket: S_IFSOCK

The low 12 bits encode permissions: 9 bits for user/group/other read/write/execute, plus 3 bits for setuid, setgid, and sticky. These are typically displayed in octal (e.g., 0644 means user read/write, group read, other read).

Ownership

The inode stores the owner’s user ID (UID) and group ID (GID) as 32-bit integers (16-bit on older file systems). These map to user and group names through /etc/passwd and /etc/group. The inode does not store the owner’s username; it stores only the numeric ID, which is why moving files between systems with different user databases can produce unexpected ownership.

Size and link count

The size field stores the file’s logical size in bytes. The link count tracks how many directory entries point to this inode; a freshly-created file has link count 1, and creating a hard link increments it to 2, etc. When the link count drops to 0, the file is deleted; the inode is freed for reuse and the data blocks are returned to the free pool.

Timestamps

Classic Unix inodes have three timestamps:

• atime (access time): updated when the file is read.
• mtime (modification time): updated when the file’s data is changed.
• ctime (change time): updated when the inode itself is changed (including permissions, ownership, link count). Note: not “creation time.”

Modern file systems extend this with creation time (crtime), sometimes called “birth time” or btime, which is the actual creation timestamp. ext4, XFS, and APFS all support crtime; ext2/3 do not. The lack of true creation time on ext2/3 is sometimes a forensic obstacle.

Block pointers (classic scheme)

The most distinctive part of a classic Unix inode is its block pointer scheme. The traditional design used in ext2 and ext3 contains:

• 12 direct block pointers: reference the first 12 data blocks of the file directly. With 4 KB blocks, this covers files up to 48 KB without any indirection.
• 1 single-indirect pointer: references a block that contains 1024 (assuming 4-byte pointers and 4 KB blocks) pointers to data blocks. Adds another 4 MB of file size.
• 1 double-indirect pointer: references a block of pointers to single-indirect blocks. Adds another 4 GB.
• 1 triple-indirect pointer: references a block of pointers to double-indirect blocks. Adds another 4 TB.

This 4-tier scheme produces O(log) access time for any block in the file (the deeper the block, the more indirection); the design is elegant but inefficient for very large files.

Block pointers (extent scheme)

Modern file systems including ext4, XFS, Btrfs, and ZFS use extent trees instead. An extent describes a contiguous run of blocks (start_block + length); a single extent can describe many megabytes of file data with just two integers. The inode contains a small extent tree header and a few inline extent descriptors; for larger files, the inline descriptors point to extent index blocks that themselves contain extent descriptors. Extent-based addressing is more space-efficient and faster than block-pointer arrays for typical files, especially large files; the trade-off is added complexity in the file system code.

Modern extensions

Modern inodes include additional fields beyond the classic structure:

• Inode flags: bits indicating immutable, append-only, no-dump, sync, etc.
• Generation number: incremented on each inode reuse to detect stale references.
• Extended attributes: arbitrary name-value pairs (xattrs) for ACLs, security labels, etc.
• Inode size: ext4 uses 256-byte inodes by default (vs 128 bytes in ext2/3) to accommodate extended fields.
• Project quota ID: for file systems supporting per-project quotas.

The separation between inodes and filenames is one of Unix’s defining architectural choices, with consequences that touch nearly every aspect of file system behavior. Understanding the separation clarifies many otherwise-puzzling Unix idioms.⁴

Filenames live in directory entries

A directory in Unix is essentially a special file whose contents are a list of (filename, inode-number) pairs. When the file system needs to look up a path like /home/user/file.txt:

1. Start with the inode for the root directory (/) at a well-known inode number (usually 2 in ext file systems).
2. Read the root directory’s data blocks to find the entry for home; get the inode number.
3. Read that inode to find the data blocks of the home directory.
4. Read those data blocks to find user; get the inode number.
5. Read that inode, find data blocks, look up file.txt, get the inode number.
6. Read the final inode to access the file’s metadata and data block pointers.

Filenames are not properties of files; they’re just keys in a directory’s lookup table. A file doesn’t “have a name”; it has a list of directory entries that reference it.

Hard links

The separation enables hard links: multiple directory entries (potentially in different directories) all pointing to the same inode. Each directory entry has its own filename, but they all reference the same underlying file. When you create a hard link with ln:

• The file system creates a new directory entry in the target directory with the new filename and the existing inode number.
• The inode’s link count is incremented.
• No data is copied; both names access the same physical file.

Removing one of the names (with rm or unlink) decrements the link count and removes the directory entry, but the file’s data persists as long as any other directory entry still references the inode (or any process has the file open).

Renames are cheap

Because renaming a file just modifies a directory entry (the inode and data blocks aren’t touched), renames are extremely cheap on Unix file systems regardless of file size. Renaming a 100 GB file takes the same time as renaming a 100-byte file: just an update to the directory entry. This is fundamentally different from systems where the filename is part of the file’s metadata.

“Deleted” while open

Unix’s classic surprising behavior: a process can hold a file open while another process deletes it; the open process continues to access the file’s data normally, even though the file no longer appears in any directory listing. This works because the inode’s link count tracks both directory entries and open file descriptors; deleting the directory entry decrements the link count to 0 from the directory’s perspective, but the open process keeps the file alive (effectively a virtual link) until it closes the file. Only then is the inode actually freed and the data blocks reclaimed.

Symbolic links are different

Symbolic links (symlinks) are different from hard links: a symlink is a special kind of file whose data is a path to another file. Resolving a symlink involves reading its data (the target path) and then looking up that path. Unlike hard links, symlinks can point to non-existent targets, can cross file system boundaries, and have their own inode separate from their target’s inode. The inode for a symlink contains the symlink’s own metadata; reading the symlink’s “content” returns the target path string.

The inode concept exists across most Unix-derived file systems, but with significant variations in implementation. Understanding the variations helps with cross-platform recovery work.

ext2/3/4: the canonical Linux family

The ext family is the most common Linux file system family and uses the most direct inode implementation:

• Fixed inode allocation: the number of inodes is set at format time and cannot grow.
• Inode tables per block group: each block group has its own inode table at a fixed offset.
• 128-byte inodes (ext2/3) or 256-byte inodes (ext4): ext4’s larger inodes accommodate creation time, nanosecond timestamps, and longer extended attributes.
• Block pointer arrays (ext2/3) or extent trees (ext4): extent trees in ext4 are more efficient but harder to recover from after deletion.

XFS: dynamic allocation

XFS uses dynamic inode allocation: rather than pre-allocating a fixed number of inodes at format time, XFS allocates inodes in chunks of 64 inodes (8 KB total) on demand. This avoids the inode-exhaustion problem that ext file systems can hit, but makes recovery more complex because inodes can be anywhere on the volume rather than at fixed table locations. XFS uses extent-based addressing (similar to ext4) for file data.

ZFS / Btrfs: object stores

ZFS and Btrfs (in different ways) deviate from the traditional inode model. ZFS uses dnodes (data nodes) that play a similar role to inodes but live in the object store rather than fixed inode tables; the dnode contains pointers to indirect blocks that ultimately reference data. Btrfs uses B-tree-based metadata where inode metadata is stored in tree nodes rather than separate inode tables. Both designs are more flexible than classic inodes but require completely different recovery techniques.

APFS: file system records

APFS (Apple File System) doesn’t use inodes in the classic sense; it uses file system records stored in B-trees. Each file is identified by a 64-bit identifier similar to an inode number, and its metadata is stored in records that the B-tree organizes. The conceptual purpose is the same (per-file metadata structure separate from filename), but the implementation is fundamentally different from Unix inodes.

HFS+: catalog file

HFS+ (Apple’s predecessor to APFS) uses a centralized catalog file that’s structurally somewhat similar to NTFS’s MFT: a single B-tree containing records for every file and directory. Each record is the conceptual analogue of an inode, but they’re organized in a tree rather than a flat table.

NTFS comparison

The contrast with NTFS is illuminating: NTFS’s MFT records play the same role as inodes (per-file metadata) but with one major design difference. MFT records contain the filename as one of their attributes ($FILE_NAME), while Unix inodes don’t. This means deleted files on NTFS retain their original filename in the MFT record (until the record is reused), making recovery substantially easier than on ext file systems where the filename lives in the directory entry that gets cleared on deletion.

Inode-based recovery is fundamental to Linux file system recovery. The inode’s central role means that successful recovery typically depends on inode state at the time of the recovery attempt.⁵

The “shell filename” problem

The Baeldung Linux recovery documentation captures a key inode-related failure mode: “Pointers within inodes refer to what most would call data, e.g., file contents. Losing or damaging an inode can invalidate content block pointers and leave files only as shell filenames. They would contain full metadata but no content.” When the inode’s block pointers are lost or corrupted, the directory entry still names the file but there’s no way to find its data; the file becomes a “shell”: present in directory listings but with no content recoverable through normal means.

debugfs: the canonical tool

The Wondershare debugfs documentation describes its central role: “Debugfs is a powerful debugging utility in the Linux operating system that provides a way to access a file system’s internal data structures and inode information. Kernel developers often use it to perform tasks such as file undeletion and data recovery.”⁶ The standard debugfs recovery procedure:

1. Open the file system in debugfs (read-only mode for safety).
2. Use lsdel to list deleted inodes; identify the target file by size, deletion time, or inode number.
3. Use stat <inode> to display the deleted inode’s full contents.
4. Note the block numbers in the inode’s block pointers.
5. Use dump <inode> /path/to/output to extract the file’s data based on the inode.
6. Verify the recovered file’s contents.

The procedure works when the deleted inode is still readable; on ext4, this often requires fast action because extent metadata is cleared more aggressively than block pointer arrays were on ext2/3.

extundelete and ext4magic

Beyond debugfs, two specialized recovery tools handle ext file systems:

• extundelete: reads the file system journal to find inode states from before recent deletions; can recover files whose current inodes are zeroed but whose pre-deletion state survives in the journal.
• ext4magic: ext4-specific tool that handles extent trees better than generic debugfs; can recover from extent-tree-cleared inodes by reconstructing extent state from journal data.

Both tools work above debugfs’s level, providing more automated recovery workflows but with the same fundamental dependency on inode-and-journal state.

Inode exhaustion as a recovery scenario

Inode exhaustion is sometimes confused with disk-full conditions. The Linux Bash documentation mentions the diagnostic command: “df -i: Displays inode usage information and availability, which is quite useful in managing filesystems.” A system reporting “no space left on device” with substantial free disk space (per df) likely has exhausted inodes; this isn’t a recovery scenario per se, but the diagnostic confusion can lead administrators to take inappropriate corrective actions.

When inodes are corrupted

Corrupted inodes (rather than zeroed) present different recovery challenges. The USPTO 11650875 patent on abnormal inode dynamic repair captures the failure mode: “During the operation of a distributed file system, a core data structure ‘inode’ of file metadata may have some missing fields or invalid field values sometimes due to some unknown anomalies, and furthermore, the file system has an error and is unable to keep on operating during request processing and inode checking because the field values are inconsistent with expected values of the file system.” Recovery from corrupted inodes requires either:

• fsck repair: the standard fsck tool can detect and repair some inode inconsistencies, though aggressive repair can lose data.
• Manual debugfs repair: for skilled administrators, debugfs can directly modify inode fields to fix specific corruptions.
• Replacement from backup: if the inode is unrecoverable, the file’s data may still be present in blocks that can be carved.

File carving as fallback

When inode recovery fails (zeroed pointers, corrupted inodes, destroyed inode tables), file carving is the fallback: scanning the entire volume looking for file signatures regardless of inode state. Carving recovers file content but loses original filenames, timestamps, ownership, and directory structure; it’s substantially less useful than inode-based recovery but provides a fallback when inodes are gone. Tools like foremost, scalpel, and photorec implement carving for various file types.