Write short notes on: I-Node

Verified Sources

May 28, 2026

In Unix-like operating systems, the file system is designed around a clean separation between file metadata, directory structure, and the actual raw data blocks stored on disk . At the core of this architecture lies the index node, universally abbreviated as the inode .

An inode is a fixed-size data structure that acts as the single source of truth for a file's metadata. Every file, directory, or system object (such as a symbolic link, socket, or hardware device) is associated with exactly one inode, which is identified by a system-wide unique integer called the i-number .

What is Contained Within an Inode?

The inode contains all the critical administrative information required by the operating system to manage, track, and secure files:

File Type: Identifies whether the object is a regular file, a directory, a character device, a block device, a FIFO pipe, a socket, or a symbolic link.
Permissions: A bitmask (such as rwxr-xr-x) defining access rights for the Owner, Group, and Others.
Ownership IDs: The User ID (UID) and Group ID (GID) of the file's owner.
File Size: The total size of the file represented in bytes.
Timestamps: Three crucial temporal markers:
1. $atime$ : Time of last access (read operation).
2. $mtime$ : Time of last content modification (write operation).
3. $ctime$ : Time of last inode status change (metadata update, such as changing permissions).
Link Count: The number of directory entries (hard links) pointing to this specific inode.
Pointers to Data Blocks: The physical disk addresses where the actual file contents reside.

What is NOT Contained Within an Inode?

Crucially, an inode does not contain:

The Filename: Filenames are stored exclusively within a parent directory's data blocks as part of a directory entry .
The Actual Data: The file's contents are stored separately in designated data blocks across the physical drive.

Wikipedia: Inode - Standard documentation on the structure and history of index nodes in Unix file systems. ↩ ↩²
IBM Developer: It is all about the inode - Comprehensive guide to Unix metadata management and file system design. ↩ ↩²

Unix Inode Structure and Pointer Mathematics Explained

Inode Block Pointer Architecture

To support files of varying scales—from tiny configuration files to massive multi-gigabyte databases—traditional Unix file systems (such as UFS and early ext systems) utilize an asymmetric, multi-level inode pointer structure .

An individual inode typically contains a fixed array of fifteen disk block pointers:

Direct Pointers (Pointers $0$ to $11$ ): The first twelve slots are direct pointer entries. They contain the physical block addresses of the first twelve data blocks of the file. If a file is small (e.g., less than $48\text{ KB}$ on a system with $4\text{ KB}$ block sizes), its data blocks are accessed directly through these pointers with zero overhead.
Singly Indirect Pointer (Pointer $12$ ): This indirect pointer points to a special "index block" instead of a data block. This index block contains an array of direct pointers to actual data blocks.
Doubly Indirect Pointer (Pointer $13$ ): This pointer points to a primary index block, which in turn points to an array of secondary index blocks. Each secondary index block then contains direct pointers to data blocks.
Triply Indirect Pointer (Pointer $14$ ): This pointer points to a primary index block, which points to secondary index blocks, pointing to tertiary index blocks, which finally point to the actual data blocks.

The Mathematics of File Size Calculation

The maximum file size supported by this traditional pointer structure depends on the configured block size ( $B$ ) and the size of a disk block pointer ( $p$ ) .

Let:

$B = 4096\text{ bytes}$ ( $4\text{ KB}$ )
$p = 4\text{ bytes}$ (32-bit disk addressing)

The number of pointers ( $N$ ) that can fit inside a single index block is: $N = \frac{B}{p} = \frac{4096}{4} = 1024 \text{ pointers}$

Using these values, we can calculate the capacity of each pointer tier:

Direct Capacity ( $C_d$ ): $C_d = 12 \times B = 12 \times 4\text{ KB} = 48\text{ KB}$
Singly Indirect Capacity ( $C_s$ ): $C_s = N \times B = 1024 \times 4\text{ KB} = 4096\text{ KB} = 4\text{ MB}$
Doubly Indirect Capacity ( $C_d$ ): $C_d = N^2 \times B = 1024^2 \times 4\text{ KB} = 1,048,576 \times 4\text{ KB} = 4,194,304\text{ KB} = 4\text{ GB}$
Triply Indirect Capacity ( $C_t$ ): $C_t = N^3 \times B = 1024^3 \times 4\text{ KB} = 1,073,741,824 \times 4\text{ KB} = 4,294,967,296\text{ KB} = 4\text{ TB}$

Maximum Theoretical File Size: $\text{Max Size} = C_d + C_s + C_d + C_t \approx 4.0039\text{ TB}$

Wikipedia: Inode Pointer Structure - Detailed explanation of direct, indirect, doubly indirect, and triply indirect block addressing. ↩ ↩²

The Inode Limit Phenomenon

A common system administration issue is running out of inodes even when there is plenty of disk space remaining. This happens when a file system contains millions of extremely small files (such as session files or tiny logs). Since every file requires exactly one inode, the system cannot create new files once the inode table is fully exhausted. Use df -i in your terminal to monitor inode usage.

Path Resolution: How the OS Resolves a File Path to an Inode

1
Step 1
The kernel begins by looking up the root directory /. The root directory always has a well-known, fixed i-number (typically inode number $2$ in ext4 file systems). The OS reads inode $2$ to locate the root directory's data blocks.
2
Step 2
The OS reads the data blocks of the root directory. In Unix, a directory is just a special file containing a list of directory entry structures. It searches this list for the name of the next component in the path (e.g., var).
3
Step 3
Once the name var is found, its associated inode number is retrieved. The kernel accesses this new inode to find the data blocks for the /var directory and searches for the next subdirectory (e.g., log).
4
Step 4
This step-by-step traversal repeats down the directory tree until the target file (e.g., syslog) is reached. The kernel retrieves the target file's inode number and loads its metadata into memory.
5
Step 5
With the final file's inode loaded, the kernel uses the direct and indirect pointers stored inside the inode to read or write the actual file data blocks on the physical storage device.

In the Linux ext4 file system, inodes are static structures allocated during file system formatting. By default, an ext4 inode is $256\text{ bytes}$ in size. It uses an extents tree structure instead of traditional indirect pointers to map large, contiguous sequences of blocks, reducing metadata overhead. The maximum number of inodes is fixed at creation time, meaning you can exhaust inodes independently of physical disk space.

Addressable File Space by Pointer Type (with 4KB block size)

Logarithmic scale representation of addressable storage capacity per pointer level (in Kilobytes)

Advanced Inode Mechanics & Edge Cases

In-Memory Inode Corruption

If a system crashes or loses power while writing to disk, the metadata in the inode might become out of sync with the actual data blocks. This is known as filesystem corruption. Unix systems use tools like fsck (File System Consistency Check) during boot to scan the inode tables, repair link counts, and recover orphaned blocks by placing them in the lost+found directory.

Knowledge Check

Question 1 of 4

Q1Single choice

Which of the following attributes is NOT stored inside an inode?

File size

File owner UID

File name

File permissions

Explore Related Topics

I2C Bus Fundamentals: How Many Lines Does I2C Use?

I2C is a two‑wire serial bus that uses SDA (data) and SCL (clock) lines for communication between multiple devices on a board.

Only two signal lines are required, making I2C a low‑pin‑count solution.
SDA carries addresses, acknowledgments and data, while SCL provides the timing clock for each bit.
Both lines are open‑drain/bidirectional with pull‑up resistors, allowing many devices to share the bus safely.
Communication starts with a START condition, proceeds with address and data transfer, and ends with a STOP condition.

Group Discussion Evaluation: Why the Correct Answer Is Communication and Teamwork

Group discussions are used in recruitment and education to assess participants' communication and teamwork rather than writing, coding, or memory.

Evaluators watch for clear speaking, active listening, relevance, collaborative engagement, and respectful conflict handling.
Leadership, initiative, and problem‑solving are secondary but still observed.
Written ability, technical coding, and pure recall are not primary targets in GDs.
Success depends on oral interaction; the core metric can be expressed as $\text{Primary GD Evaluation} \approx \text{Communication} + \text{Teamwork}$ .

Understanding Digital Counters: Principles, Types, and Applications

Digital counters are sequential circuits built from cascaded flip‑flops that count input events, with a maximum modulus of 2ᴺ for N stages, and are classified as asynchronous (ripple) or synchronous based on clock distribution.

Asynchronous counters cascade flip‑flop clocks, causing cumulative propagation delay and limiting maximum frequency.
Synchronous counters receive the clock simultaneously, using combinational logic to eliminate ripple delay and support higher speeds.
Designing a synchronous Mod‑6 counter involves defining the state sequence, creating excitation tables, simplifying with Karnaugh maps, and wiring JK flip‑flops with derived logic.
Ring counters yield N states; Johnson counters double this to 2N states.
Prevent glitches and lock‑out by using Gray‑code sequencing, output strobes, and ensuring unused states redirect to the main count sequence.

Research more with Coursify