Inodes & File Metadata

Run ls -la on any file and the output shows a filename, permissions, an owner, a size, a timestamp. It feels like all of that is stored together — one tidy bundle called "a file."

It's not. The filename is stored in one place. Everything else — permissions, ownership, timestamps, the location of the actual data on disk — is stored in a completely separate structure called an inode. The filename just points to it.

This split is not an implementation detail. It's the reason hard links work, the reason a file can be deleted while a process is still reading it, and the reason a server can die with "No space left on device" while sitting on 200 GB of free disk.

What Actually Happens

When the kernel needs to access a file's metadata, the sequence is:

1. Resolve the pathname through the dentry cache to get an inode number
2. Check the inode cache — a kernel hash table keyed by (superblock, inode number)
3. If it's cached, return it immediately
4. If not, call the filesystem's read_inode() to load the on-disk inode (e.g., ext4_inode) into a VFS struct inode

The VFS inode is the filesystem-independent version. Every filesystem driver must populate it, which is how the kernel provides a uniform interface across ext4, XFS, Btrfs, NFS, and everything else.

Here's what lives inside the inode — and what doesn't:

Stored in the inode: permissions (mode), owner (uid/gid), size, hard link count, timestamps (atime/mtime/ctime), and pointers to the data blocks on disk.

NOT in the inode: the filename. That lives in directory entries, which are separate structures that map name strings to inode numbers.

This separation is what makes hard links possible: multiple names, one inode, one set of data blocks.

Under the Hood

The link count and unlink-while-open. The st_nlink field tracks how many directory entries point to this inode. When unlink() removes a name, it decrements st_nlink. But the kernel doesn't free the inode and its data blocks until two conditions are met: st_nlink reaches zero AND no process has the file open. This means a file's last name can be deleted while a process is still reading it — the process keeps its fd, keeps reading, and the disk space is only reclaimed when it closes the fd. This is foundational for atomic file replacement and safe log rotation.

Timestamps: atime, mtime, ctime. mtime updates when the data is modified. ctime updates when anything about the inode changes — permissions, ownership, link count, or data (since data changes also update the size field). atime updates on read, but the relatime mount option (default since Linux 2.6.30) only updates atime if it's older than mtime, dramatically reducing write I/O. noatime disables it entirely — common for database workloads where every read was generating a write.

Inode size and allocation. ext4 uses 256-byte inodes (ext3 used 128). The extra space stores extended attributes (xattrs), nanosecond timestamps, and inline data for tiny files. The ratio of inodes to disk space is set at mkfs time with the -i (bytes-per-inode) option. The default of one inode per 16 KB works for most workloads. But a mail server storing millions of tiny files needs more inodes (smaller bytes-per-inode), and a video storage server with few large files needs fewer.

Extents, not block pointers. Old-school filesystems (ext2, ext3) stored block pointers — one pointer per data block. For a 1 GB file with 4 KB blocks, that's 262,144 pointers. Modern filesystems (ext4, XFS, Btrfs) use extents: a single (start block, length) pair describes a contiguous run. One extent can replace thousands of pointers. ext4 stores up to 4 extents directly in the inode. If the file is fragmented beyond that, it builds an extent tree — a B-tree of extents rooted in the inode.

Common Questions

Why can't hard links cross filesystem boundaries?

Because inode numbers are only unique within a single filesystem (identified by st_dev). Inode 42 on /dev/sda1 is a completely different file than inode 42 on /dev/sdb1. A directory entry on one filesystem can't reference an inode on another — there's no cross-device lookup mechanism. Symlinks solve this by storing a pathname string, which the VFS resolves through path walk at access time, potentially crossing mount points.

A process opens a file, then someone deletes it. What happens to disk space?

The directory entry is removed and st_nlink drops to zero, but the inode and data blocks are NOT freed until the last fd referencing it is closed. This is why du and df can disagree: du walks directory entries (which are gone), while df checks actual block allocation (still in use). Use lsof +L1 to find deleted files still held open by processes — it's one of the most common causes of "where did my disk space go?"

What's the difference between ctime and mtime?

mtime records when the file's data was last modified — writes, truncates. ctime records when the inode metadata was last changed — that includes permission changes (chmod), ownership changes (chown), link count changes (link/unlink), and also data changes (because they update size/blocks in the inode). ctime cannot be set explicitly; the kernel always maintains it. This makes ctime useful for detecting any kind of file tampering, including metadata-only changes that mtime would miss.

How does statx() improve on stat()?

Five ways: (1) birth time — actual file creation time — via STATX_BTIME. (2) Selective field requests via a mask, so callers can skip expensive operations like NFS attribute refresh with AT_STATX_DONT_SYNC. (3) Attribute flags like STATX_ATTR_COMPRESSED and STATX_ATTR_ENCRYPTED. (4) Proper nanosecond timestamp support. (5) Extensibility — new metadata fields can be added without inventing new syscalls. For new code that calls stat(), statx() is the better choice.