the inode in depth

When you think of a file you probably think of its name, but a file's name is not really part of the file. The actual file - its size, its permissions, its timestamps, and crucially the list of where its data lives on disk - is described by a separate record called an inode. The name is just a label in some directory that points at an inode by number. Understanding the inode is understanding what a file truly is underneath the name.

An inode (index node) is a fixed-size on-disk structure, one per file, identified by an inode number. It holds the file's metadata: the type (regular file, directory, symlink, device), the permission bits and owner/group ids, the link count (how many directory entries point at this inode), the size in bytes, and the timestamps (modification time mtime, access time atime, and the inode-change time ctime). It does NOT hold the filename. Most importantly it holds the map from file offsets to disk blocks - in classic Unix filesystems, a set of direct block pointers plus single, double, and triple indirect pointers; in modern ones like ext4 or XFS, a small extent tree. To read byte 100000 of a file the kernel reads the inode, follows that map to the physical block, and reads it.

Why it matters: separating the name from the inode is what makes hard links possible - two names, one inode, link count 2 - and what makes a file survive being unlinked while still open (the inode and data are freed only when both the link count and the open count reach zero). It is also why filesystems can run out of inodes even with free disk space: inodes are allocated from a fixed-size table created when the filesystem was formatted, so millions of tiny files can exhaust inodes long before they exhaust blocks. The reverse can happen too. A common misconception is that deleting a file with rm erases its data; rm only removes a directory entry and decrements the link count - the inode and its blocks are reclaimed only when nothing references them anymore.