1. Start with the Familiar File

When you browse your storage, you see files organized neatly into folders:

A user or an application interacts with a file as a single, continuous stream of bytes. You open the file, write some text, read it back, and close it.

But this continuity is a software abstraction. The underlying physical storage device has no concept of a "file," a "name," or a "directory." It does not know where notes.txt begins or ends.

Instead, storage devices operate purely in terms of fixed-size data blocks.

The key realization is simple:

2. From File to Blocks

When a file is written to storage, the filesystem must divide the continuous file bytes into discrete, block-sized chunks.

Suppose notes.txt is exactly 10 KB in size, and the filesystem organizes storage into 4 KB blocks. The filesystem splits the file as follows:

* Block 1: Bytes 0 to 4,095 (4 KB) → Storage Block 120 * Block 2: Bytes 4,096 to 8,191 (4 KB) → Storage Block 121 * Block 3: Bytes 8,192 to 10,239 (2 KB used) → Storage Block 122

Notice that the final block (Block 122) contains only 2 KB of file content, but it still consumes a full 4 KB block on disk. The remaining 2 KB of that block cannot be allocated to another file, resulting in internal fragmentation.

This block-based translation is handled entirely by the operating system's filesystem driver.

3. A File's Blocks Do Not Have to Be Physically Adjacent

Because the filesystem maps logical segments to storage blocks through an index, a file's blocks do not need to sit next to each other on the physical drive.

A file could easily be scattered across the storage medium:

This establishes an important separation of concerns:

1. Logical File Order: A continuous byte sequence starting at 0 and running to 10,239. 2. Physical Block Locations: Scattered blocks (120, 121, 245) residing wherever space was available when the write occurred.

The storage hardware does not know these blocks are related; it simply reads and writes individual blocks as commanded.

4. Classic Storage Allocation Strategies

How does the filesystem keep track of which blocks belong to which files? Historically, three classic allocation strategies were designed to solve this mapping problem:

Contiguous Allocation The filesystem places the entire file's blocks in consecutive sequence on the storage device. * Advantage: Extremely fast sequential access, as the device read heads (in HDDs) or controller logic (in SSDs) do not need to jump addresses. * Disadvantage: Prone to external fragmentation. As files are created and deleted, finding consecutive blocks large enough for new files becomes increasingly difficult.

Linked Allocation Each block contains a small pointer to the next block, forming a chain. * Advantage: No block space is wasted due to external fragmentation; any free block can join the chain. * Disadvantage: Poor random access performance. To read Block 50, the OS must read Blocks 1 through 49 first to follow the pointers.

Indexed Allocation All data block pointers are collected together in a single dedicated index block. * Advantage: Supports fast direct/random access to any block without reading preceding data. * Disadvantage: Overhead. Even tiny files consume an entire extra block just to hold the index mapping.

5. Important Clarification

Modern operating system filesystems rarely implement these classic models in their raw textbook form. Instead, they use advanced adaptations:

* Extents: Rather than indexing every block individually, modern filesystems allocate ranges of consecutive blocks. An extent is simply a (Start Block, Run Length) pair. For example: "Start at Block 120 and read the next 8 blocks." * B-Trees / Extent Trees: Large files index their extents inside tree structures, allowing quick lookups and scaling to petabytes of data.

The fundamental goal, however, remains the same: translating a single logical file stream into a set of mapped storage block addresses.

6. EdgeCase: From File to Blocks

Use the simulator below to visualize how the filesystem translates a 10 KB file into logical blocks, maps them to physical sectors, and services a read request from the middle of the file:

7. Do Not Overclaim Physical Placement

While the filesystem maps files to "Storage Blocks," it is important to realize that these storage blocks are still logical representations.

On modern Solid State Drives (SSDs) and NVMe drives, there is another translation layer inside the device itself. When the filesystem requests Logical Block Address (LBA) 120, the SSD controller's Flash Translation Layer (FTL) intercepts the request and maps it to a physical flash memory cell.

The SSD controller does this to balance wear across its silicon gates, handle bad blocks, and optimize write performance. The operating system filesystem manages logical block layouts, while the storage drive controller manages the actual physical hardware mapping.

8. Real Operating-System Connection

Most production operating systems rely heavily on extent-based allocation instead of raw block mapping:

* Linux (ext4): Uses extent trees to store metadata. A single extent can represent up to 128 MB of contiguous space on a 4 KB block filesystem, reducing metadata overhead significantly. * Windows (NTFS): Refers to extents as data runs. The MFT record describes files as a series of runs mapping logical clusters to physical storage clusters. * macOS (APFS): Employs dynamic extent allocation paired with copy-on-write clones, letting multiple directory entries reference the same extents until a write is made.

9. Connection to Fragmentation

In the Memory Management branch, we saw how memory becomes fragmented as pages are allocated and freed. The same phenomenon occurs in storage.

When a file's blocks are scattered far apart on physical storage, the file is fragmented: * On Hard Disk Drives (HDDs): Fragmentation is highly destructive to performance. The mechanical drive head must physically rotate and seek to jump between distant sectors, causing noticeable delays. * On Solid State Drives (SSDs): There are no moving heads, so mechanical seek delays do not apply. However, extreme fragmentation still imposes CPU overhead on the filesystem driver (which must manage massive mapping tables) and limits the drive controller's ability to run parallel block operations.

10. The Next Question

We now know that a file is a logical object whose data is mapped onto storage blocks.

But those blocks do not exist in isolation.

What exactly is the layer between the filesystem and the storage device — and how do partitions, volumes and filesystems turn a raw device into something the OS can actually use?