Fundamentals 24 min read

Why Linux Treats Everything as a File: A Deep Dive into Its File System

This article explains how Linux models all resources—including disks, devices, and inter‑process communication—as files, describes the physical storage mechanisms of hard drives, and walks through the steps of partitioning, formatting, mounting, and navigating the Linux file system hierarchy.

ITPUB
ITPUB
ITPUB
Why Linux Treats Everything as a File: A Deep Dive into Its File System

Introduction

Linux follows the Unix principle that every resource—documents, directories, keyboards, monitors, disks, printers, sockets, and even inter‑process communication—appears as a file in the file‑system namespace. This uniform view lets the same APIs ( read, write) and tools ( cat, redirection, pipelines) operate on any I/O object.

Mechanical Hard‑Disk Storage

Most modern computers still rely on the magnetic storage principles of mechanical hard drives, which SSDs and flash inherit conceptually. A disk consists of multiple platters, each divided into concentric tracks, sectors (512 bytes), clusters, and cylinders. The image below illustrates these layers:

When reading or writing, the OS uses the inode number to locate the correct track and sector, then accesses data cylinder by cylinder.

Linux File System Overview

Linux represents data and hardware resources as files, classified into regular files, directory files, device files, symbolic links, FIFO pipes, and socket files. These are organized in a single hierarchical directory tree rooted at /. The file system (e.g., ext2, ext3, XFS) is mounted via the Virtual File System (VFS) layer, which abstracts the underlying storage format.

File Types

Regular file (-) : user data such as .mp4, .pdf, .html.

Directory file (d) : a special file that contains entries mapping names to inode numbers.

Symbolic link (l) : a pointer to another file, similar to a Windows shortcut.

Block (b) and character (c) device files : represent hardware like disks (block) or serial ports (character) under /dev.

FIFO (p) : a named pipe for inter‑process communication.

Socket (s) : endpoint for network or local IPC.

Partitioning

Before a disk can be used, it is divided into partitions, which are logical divisions of the physical device. The first sector (MBR) holds the boot loader (446 bytes) and a partition table (64 bytes) that can describe up to four primary partitions. To exceed this limit, an extended partition is created, which can contain multiple logical partitions.

Up to four entries in the primary partition table.

Only one extended partition is allowed.

The extended partition can be split into many logical partitions.

Only primary and logical partitions can hold data; the extended partition itself contains no data.

Linux supports up to 59 logical partitions on IDE disks and 11 on SATA disks.

A swap partition is typically created to hold pages that are evicted from RAM.

Formatting

Each partition must be formatted with a file system (e.g., ext2, ext3, XFS). The VFS layer accesses the appropriate driver based on the file‑system type. Ext2 is an inode‑based file system where metadata resides in inodes and file contents reside in data blocks.

Key Structures

Inode table : stores file attributes (size, permissions, timestamps, owner, block pointers). Each inode is 128 bytes (or 256 bytes on newer ext4/XFS). A file may require direct, indirect, double‑indirect, and triple‑indirect block pointers.

Data block : holds the actual file data. Block size can be 1 KB, 2 KB, or 4 KB, affecting maximum file and file‑system sizes.

Superblock : 1 KB structure containing global file‑system metadata (total blocks/inodes, free counts, block/inode sizes, mount status, timestamps).

Block bitmap : tracks which data blocks are free or used.

Inode bitmap : tracks which inodes are free or used.

Mounting

After formatting, a file system must be mounted so that the kernel can access it. Mounting attaches the file system to a directory (the mount point), making its contents reachable through the directory tree. The root file system is always mounted at /, while other partitions can be mounted elsewhere as needed.

Reading the Directory Tree

To read a file, the kernel traverses the directory hierarchy:

Each file and directory has an inode.

Blocks are allocated based on file size.

Creating a file stores its name in the parent directory’s block, its metadata in a new inode, and its data in one or more data blocks.

Renaming or moving a file only changes directory entries; the inode and data blocks remain unchanged.

Example: Reading /etc/passwd

1 $ ll -di / /etc /etc/passwd
2 128 dr-xr-x r-x . 17 root root 4096 May 4 17:56 /
3 33595521 drwxr-x r-x . 131 root root 8192 Jun 17 00:20 /etc
4 36628004 -rw-r-- r-- . 1 root root 2092 Jun 17 00:20 /etc/passwd

The lookup proceeds as follows:

Root inode 128 provides the block containing the / directory.

The block reveals inode 33595521 for /etc.

Inode 33595521 gives access to the block that lists passwd with inode 36628004.

Inode 36628004 shows read permission, allowing the kernel to fetch the data block and return the file’s contents.

Conclusion

Linux’s “everything is a file” model simplifies API design by reducing resource interaction to a small set of atomic operations (read/write). Understanding the physical storage layout, partitioning, formatting, inode structures, and mounting process is essential for system administrators, developers, and anyone working with Linux at a low level.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

Linuxfile systemfundamentalsinodesPartitionsMounting
ITPUB
Written by

ITPUB

Official ITPUB account sharing technical insights, community news, and exciting events.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.