Inodes concept in Linux CLI - Step-by-Step Execution

Concept Flow - Inodes concept

File created

↓

Allocate inode

↓

Store metadata in inode

↓

Store data blocks separately

↓

File linked to inode

↓

Access file via inode

↓

Modify metadata or data

↓

Delete file

↓

Decrement inode link count

↓

If link count=0, free inode and data blocks

This flow shows how a file is linked to an inode that stores metadata, how data blocks are separate, and how deletion frees inode when no links remain.

Execution Sample

Linux CLI

ls -i example.txt
rm example.txt
ls -i example.txt

Shows inode number of a file, deletes the file, then tries to list inode again to show it is gone.

Execution Table

Step	Command	Action	Output	Explanation
1	ls -i example.txt	List inode number of example.txt	123456 example.txt	Shows inode number 123456 linked to example.txt
2	rm example.txt	Remove example.txt file		Decrements inode link count; if zero, inode and data blocks freed
3	ls -i example.txt	Try to list inode of deleted file	ls: cannot access 'example.txt': No such file or directory	File no longer exists; inode freed

💡 File deleted, inode freed, so file no longer listed

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 3
example.txt inode link count	1	1	0	0
example.txt inode exists	Yes	Yes	No	No
example.txt data blocks	Allocated	Allocated	Freed	Freed

Key Moments - 3 Insights

Why does the inode number stay the same when renaming a file?

Because renaming changes the filename linked to the inode but does not change the inode itself, as shown by inode number remaining constant in step 1.

What happens to the inode when the last link to a file is removed?

The inode link count drops to zero, so the inode and its data blocks are freed, as shown after step 2 in the execution_table.

Why can't we access the file after deletion even though the inode existed before?

Because deleting the file removes the directory entry linking to the inode, and if no other links exist, the inode is freed, so the file is inaccessible as in step 3.

Visual Quiz - 3 Questions

Look at the execution table, what is the inode number of example.txt at step 1?

A 123456

B 0

C Not shown

D Deleted

💡 Hint

Check the Output column in row for step 1 in execution_table

At which step does the inode link count become zero?

A Step 1

B Step 2

C Step 3

D Never

💡 Hint

Look at variable_tracker row for 'example.txt inode link count' after each step

If we create a hard link to example.txt before deletion, what changes in the inode link count after rm?

A Link count stays 1

B Link count becomes 0

C Link count becomes 2

D Link count becomes -1

💡 Hint

Inode link count decreases by one per link removed; with a hard link, one link remains after rm

Concept Snapshot

Inodes store file metadata (permissions, owner, timestamps).
Each file has an inode number linking directory entry to inode.
Data blocks hold file content separately.
Deleting a file removes directory link; inode freed if no links remain.
Inode number stays same when renaming or linking files.

Full Transcript

In Linux, every file is represented by an inode, which stores metadata like permissions, owner, and timestamps. When you create a file, the system allocates an inode and links the filename to it. The actual file data is stored in separate data blocks. Using the command 'ls -i filename' shows the inode number. When you delete a file with 'rm', the system removes the directory entry linking to the inode and decreases the inode's link count. If the link count reaches zero, the inode and its data blocks are freed, making the file inaccessible. Renaming a file does not change its inode number because only the directory entry changes. Hard links increase the inode link count, so deleting one link does not free the inode until all links are removed.