Inodes, links, and file systems
Behind every file name sits an inode holding the file's metadata. Understanding inodes explains hard links, symbolic links, and how file systems store data.
Inodes
In Linux file systems, each file is represented by an inode, a data structure holding metadata: type, permissions, owner, group, size, timestamps, link count, and pointers to the data blocks. The file's name is not in the inode; directories are lists of names mapped to inode numbers. ls -i shows inode numbers, and stat shows full inode details.
Timestamps
Each inode records modification time (mtime, when content last changed), status change time (ctime, when metadata such as permissions last changed), and access time (atime, when last read, often updated lazily for performance, as with the relatime option). Many file systems also record a creation or birth time. Tools such as make and backup programs rely on mtime.
Hard links
A hard link is an additional directory entry pointing to the same inode: ln original.txt copy.txt makes both names refer to identical data. The inode's link count tracks how many names point to it, and the data is freed only when the count reaches zero and no process has the file open. Hard links cannot span file systems or, normally, point to directories.
Symbolic links
A symbolic (soft) link is a small special file containing a path to another file: ln -s /opt/app-2.1 /opt/app. Symlinks can cross file systems and point to directories, and are widely used for versioned installations and configuration. If the target is moved or deleted, the symlink dangles, pointing to nothing; ls -l shows symlinks with an arrow to their target.
File types
Linux files include regular files, directories, symbolic links, character devices (such as terminals), block devices (such as disks), named pipes (FIFOs), and sockets. ls -l shows the type as the first character: - for regular, d for directory, l for link, c and b for character and block devices, p for pipe, and s for socket.
File system types
ext4, the default on many distributions, is a mature journaling file system. XFS, the default on Red Hat Enterprise Linux, excels with large files and parallel workloads. Btrfs supports snapshots, checksums, compression, and multiple devices, and is the default on Fedora workstations and openSUSE. FAT32 and exFAT are used for USB drives and EFI partitions for compatibility; tmpfs lives entirely in memory.
Journaling and integrity
A journaling file system writes intended metadata changes to a journal before applying them, so after a crash it replays or discards incomplete operations rather than scanning the whole disk. Copy-on-write file systems such as Btrfs and ZFS never overwrite data in place, which enables cheap snapshots and, with checksums, detection of silent data corruption.
Worked example
echo hello > a.txt creates a file with inode 1234 and link count 1. ln a.txt b.txt adds a second name: ls -li shows both with inode 1234 and link count 2. ln -s a.txt c.txt creates a symlink with its own inode. rm a.txt drops the link count to 1: b.txt still reads 'hello', but c.txt now dangles, because it pointed to the name a.txt, not the inode.
Key takeaways
Inodes hold file metadata and block pointers; directories map names to inode numbers; ls -i and stat reveal them. Files carry mtime, ctime, atime, and often birth times. Hard links are extra names for the same inode, tracked by link count, and cannot cross file systems. Symbolic links store paths, can cross file systems and point to directories, and can dangle. ls -l shows file types such as -, d, l, c, b, p, and s. ext4, XFS, and Btrfs are major Linux file systems, with FAT32, exFAT, and tmpfs for special uses. Journaling speeds crash recovery; copy-on-write enables snapshots and checksums.
Flashcard
Stores file metadata and block pointers
Check your understanding
After rm original.txt, a hard link and a symbolic link that both pointed to it behave differently. Why?