On Linux, the filename you see is not the whole file. Behind that name is a filesystem record called an inode. The inode helps Linux keep track of the file’s identity, permissions, owner, size, timestamps, link count, and the information needed to find the file’s data.

The simplest mental model is this: a directory connects a filename to an inode number, and the inode describes the underlying file object. That separation explains several Linux behaviors that can otherwise seem strange, including hard links, renamed files, deleted-but-still-open log files, and systems that run out of inodes even when disk space remains.

The Filename Is Not Stored In The Inode

A common beginner assumption is that an inode contains the full pathname of a file. Normally it does not. A directory entry stores a name and associates that name with an inode number. The inode then stores metadata about the file itself.

This is why Linux can rename a file without creating a completely new file object. The directory entry can change while the inode remains the same. The Linux inode(7) manual page describes the inode number, file type and mode, hard-link count, owner IDs, timestamps, size, and related metadata associated with a file.

What An Inode Stores

The exact on-disk structure depends on the filesystem, but an inode commonly represents information such as the file type, permissions, owner and group IDs, file size, timestamps, hard-link count, and filesystem-specific information used to locate the file’s data.

• File type: regular file, directory, symbolic link, device, socket, and other types.
• Permissions: the read, write, and execute mode bits.
• Ownership: numeric user and group IDs.
• Size: the logical size of the file.
• Timestamps: metadata such as modification and status-change times.
• Link count: how many directory entries hard-link to the same file object.
• Data-location information: filesystem-specific structures used to reach the file’s stored data.

The inode is therefore closely related to several ideas already covered on BitcoinVersus.Tech. A program may reach an open file through a file descriptor, while a system call such as open() or stat() asks the kernel to work with that file information.

Inode Numbers Are Only Unique Inside One Filesystem

Every file in a filesystem has an inode number, but the number is not a universal ID across the whole computer. Inode numbers are unique within a particular filesystem. Another filesystem can reuse the same number for a completely different file.

That matters when you work with multiple disks, partitions, containers, or mounted filesystems. An inode number only makes sense together with the filesystem that owns it.

How To See An Inode Number

The quickest command is ls -i:

ls -i notes.txt

You can also use stat for a much fuller view:

stat notes.txt

The output includes the inode number along with size, permissions, ownership, link count, and timestamps. This is often more useful than simply listing a directory because it lets you inspect the actual metadata attached to the file object.

Hard Links Make Inodes Easier To Understand

A hard link is another directory entry that points to the same inode. That means two different filenames can refer to the same underlying file object. Neither name is inherently the “real” one; both names resolve to the same inode.

echo "hello" > original.txt
ln original.txt second-name.txt
ls -li original.txt second-name.txt

If both names are on the same filesystem, ls -li will show the same inode number for both. This is the core idea behind hard links and symbolic links: hard links share the underlying inode, while a symbolic link is a separate file that refers to another path.

Day 19 – Inodes, symlinks and other shortcuts
byu/livia2lima inlinuxupskillchallenge

Deleting A Filename Does Not Always Delete The Data Immediately

When you remove one hard link, Linux removes that directory entry and reduces the inode’s link count. The underlying file storage is normally reclaimed only when no directory entries remain and no running process still has the file open.

This explains the classic “deleted log file still using disk space” problem. A service can keep an open file descriptor to a file after its pathname has been removed. The filename is gone from the directory, but the running process still has access to the file object until it closes that descriptor or exits. Linux exposes process information through places such as /proc, which can help you investigate cases like this.

You Can Run Out Of Inodes Before You Run Out Of Bytes

Disk capacity and inode availability are not the same thing. A filesystem containing enormous numbers of tiny files can exhaust its available inode resources even while storage blocks remain free. The symptom may still look like a space problem because new files can no longer be created.

df -h
df -i

df -h shows normal filesystem space usage. df -i shows inode usage instead. The GNU Coreutils documentation describes --inodes as reporting inode usage rather than block usage.

A Useful Troubleshooting Sequence

1. Use df -h to check normal disk-space usage.
2. Use df -i to check inode usage.
3. Use ls -li when you suspect two names may point to the same inode.
4. Use stat filename to inspect metadata and link count.
5. Use find with an inode number when you need to locate another directory entry referring to the same inode on that filesystem.
6. If a deleted file still consumes space, check whether a running process still has it open.

find /path/to/filesystem -inum 123456

The Short Version

A Linux filename is a directory entry. The inode is the filesystem record behind the file. It stores metadata and identifies the underlying file object inside that filesystem. Multiple hard-link names can share one inode, inode numbers are only unique within a filesystem, and inode exhaustion can prevent new file creation even when byte capacity remains.

If you remember one sentence, remember this: the pathname tells Linux how to find the file; the inode tells the filesystem what file it found.

Editor’s Note

Inode implementation details vary by filesystem. Commands and concepts in this explainer describe the Linux/Unix filesystem model at a practical systems-administration level rather than the exact on-disk layout of every filesystem.

BitcoinVersus.Tech is independently maintained. Support options on the site help fund additional technical research, verification, and open educational publishing.

BitcoinVersus.tech is not a financial advisor. Content is provided for informational purposes.