Files, Inodes, and Metadata

A file on Linux is not the name you type. The name is a directory entry; the file itself is an inode — a fixed-size record on disk that holds every attribute of the file except its name and its contents. Size, owner UID and group GID, the permission bits, the three timestamps, the link count, and the pointers to the data blocks all live in the inode. The directory entry is just a string mapped to an inode number, and the kernel resolves the rest from there.

That separation between name and inode is the single fact that explains hard links, why rm does not always free space, why renaming a 50 GB file inside one filesystem is instant, and why a filesystem can run out of files while gigabytes of disk sit empty. Once you see directory entries as pointers to inodes rather than as the files themselves, the rest of the filesystem stops surprising you.

The Inode

Every file, directory, symlink, device node, socket, and named pipe is an inode. When a filesystem like ext4 or XFS is created, ext4 allocates its inode table up front — a fixed count decided at mkfs time — while XFS grows inodes dynamically as needed. Each inode carries a number, unique within that filesystem, and that number is what a directory entry actually references. Run stat on any path and you are reading the inode straight out, name aside.

# stat shows the inode contents: number, size, blocks, mode, owner, times
stat /etc/hosts
  File: /etc/hosts
  Size: 221       Blocks: 8          IO Block: 4096   regular file
Device: 259,2   Inode: 1442        Links: 1
Access: (0644/-rw-r--r--)  Uid: (0/root)   Gid: (0/root)
Modify: 2026-05-12 09:41:08
 Birth: 2026-05-12 09:41:08

What the inode does not store is the filename. There is no field for it, and a single inode can be reached by many names at once. The kernel finds an inode by walking directory entries to its number, then reads the inode to learn where the data blocks are and whether the caller is allowed to touch them.

Directory Entries and Hard Links

A directory is itself an inode whose data is a table of (name, inode number) pairs. A hard link is nothing more than a second directory entry pointing at the same inode. Both names are equal — neither is the "original" — and the inode's link count tracks how many names refer to it. The kernel only frees the inode and its data blocks when that count reaches zero and no process still holds the file open.

# two names, one inode: note the identical inode number and Links: 2
echo "payload" > a.txt
ln a.txt b.txt
ls -li a.txt b.txt
1442 -rw-r--r-- 2 root root 8 May 30 11:02 a.txt
1442 -rw-r--r-- 2 root root 8 May 30 11:02 b.txt
rm a.txt   # link count drops to 1; data survives under b.txt

This is why rm is more honestly named unlink — it removes a directory entry and decrements the link count, not the bytes. It also explains the classic disk-space surprise: delete a 10 GB log that a running process still has open, and df shows no space recovered. The directory entry is gone, but the link count is still held by the open file descriptor, so the inode and its blocks stay allocated until the process closes the file or restarts.

Hard links carry one hard constraint: they cannot cross filesystem boundaries, because an inode number is only meaningful within its own filesystem. You also cannot hard-link a directory — that restriction exists to keep the directory tree acyclic.

Symbolic Links

A symbolic link is a different mechanism entirely. It is its own inode whose data is a text string — a path to another file. The kernel follows that string at lookup time, which means a symlink can point across filesystems, point at a directory, and point at a target that does not exist yet or has since been deleted (a dangling link). Where a hard link is indistinguishable from the file, a symlink is a signpost that can rot.

Property	Hard link	Symbolic link
What it stores	Same inode number	A path string
Crosses filesystems	No	Yes
Can target a directory	No	Yes
Survives target deletion	Yes — it is the file	No — becomes dangling
Affects target link count	Yes (+1)	No

On Debian and Ubuntu this matters daily: /etc/alternatives is a tree of symlinks selecting which binary editor or java resolves to, and systemd enables a unit by creating a symlink from a .wants directory to the unit file under /usr/lib/systemd/system. Use ln -s target linkname to create one and readlink -f to resolve it all the way to the real path.

Permission Bits and Ownership

The inode stores a 16-bit mode: the file type, the special bits (setuid, setgid, sticky), and the nine permission bits for owner, group, and other. Those nine bits are what chmod 0644 sets and what the first column of ls -l renders. Ownership is two numeric IDs in the inode — UID and GID — and the names ls prints are looked up from /etc/passwd and /etc/group at display time, not stored on disk.

The special bits are easy to overlook and expensive to get wrong. Setuid (4000) on an executable makes it run as the file's owner rather than the caller — that is how /usr/bin/passwd runs as root for an unprivileged user, and it is the first thing an attacker hunts for. Setgid (2000) on a directory forces new files to inherit the directory's group, which is the standard way to run a shared project directory. The sticky bit (1000) on /tmp stops users from deleting each other's files in a world-writable directory.

Timestamps and Extended Attributes

The inode keeps three timestamps, and the difference between them traps people. atime is last access, mtime is last content modification, and ctime is last inode change — a permission change, an ownership change, or a link-count change bumps ctime but leaves mtime alone. There is no creation time in the classic inode; ext4 and XFS added a fourth, crtime (birth), which stat shows as "Birth" when the filesystem records it. Modern mounts default to relatime, which only updates atime when it lags mtime, so do not trust atime as a precise read log unless the filesystem is mounted strictatime.

Beyond the fixed fields, files carry extended attributes — arbitrary name/value pairs in namespaces. The security.* namespace is where AppArmor and SELinux labels live; system.posix_acl_access holds POSIX ACLs that extend permissions past the single owner/group/other model. View them with getfattr -d and ACLs with getfacl; on Debian and Ubuntu the userland tools come from the attr and acl packages. A plain cp drops xattrs and ACLs — you need cp -a or cp --preserve=all to carry them.