When you save a file and hit “save”, almost nobody thinks about what happens inside the disk. The reality is stranger than the folder icon suggests: your file is not stored as one continuous block, but as a collection of pieces scattered across the device, held together by a set of invisible records called inodes.
To understand this, it helps to separate two concepts that are often mixed up: the file system (the logical structure that organizes data, such as ext4 on Linux or APFS on macOS) and the block device (the physical disk or SSD that stores raw bytes). Between them lies a layer of abstraction: the file system translates the names and paths you understand into physical addresses inside that sea of sectors.
The inode: the file’s index card
The centerpiece of almost every Unix-style file system is the inode (index node). Think of it as a catalog card holding everything the system needs to know about a file: its owner, permissions, timestamps and, above all, the list of blocks where its data lives. What the inode does not store is the file’s name. The name lives elsewhere.
That “elsewhere” is the directory. Although you see it as a folder, to the system it is simply a special file whose contents are a table of pairs: each entry associates a name with an inode number. That is why, on Unix systems, a file can have several names (the so-called hard links): they all point to the same inode, and the file truly disappears only when the last link is deleted and the inode’s reference counter reaches zero.
From loose blocks to extents
In older file systems, each inode stored a list of pointers to individual blocks (typically 4 KiB each). That forced the system to jump from one pointer to the next to read a large file — a slow process. ext4, the default file system on most Linux distributions, solved this with extents: instead of enumerating block by block, each inode entry describes a contiguous range (start address and length). A one-gigabyte file may need only a handful of extents instead of thousands of individual pointers, which greatly speeds up reads and reduces fragmentation.
There is more. ext4 uses delayed allocation: it postpones deciding where to write the blocks until the last moment, once it knows the file’s final size, so it can group them into contiguous zones. It also batches several write requests into a single operation (multiblock allocation), reducing the disk’s workload.
Journaling: a diary that saves you
Imagine the power going out right in the middle of an operation that updates several blocks at once. If the system is left halfway through, it could end up with the inode updated but the data half-written, or with the directory table pointing at an inode that does not exist. In the past, that caused dreaded corruption and forced a full disk check (fsck) that could take hours.
To avoid this, modern file systems use journaling: before touching the real data, they write a description of what they are about to do in a separate area called the journal. If the system crashes halfway through, on boot it replays the journal and redoes or undoes the incomplete operation until the system is consistent again. ext4 applies this by default in ordered mode: first it logs the metadata, then writes the data, and only then marks the operation as complete. The result is that a power cut almost never corrupts a modern ext4 disk.
When the disk is an SSD
Everything above describes file system logic, which is independent of the physical medium. But if the device is an SSD (a solid-state drive based on flash memory), an extra layer appears: the flash translation layer (FTL). Flash cannot overwrite a block in place; it must first erase it, and erasure is only possible in large blocks. To hide this limitation, the SSD controller constantly relocates data and keeps a logical-to-physical map — a process called wear leveling that spreads writes so that no cell degrades before the others.
Here a mostly unnoticed instruction comes into play: TRIM. When you delete a file, the file system does not clean the data: it only marks the blocks as free in its own structures. The file system must tell the SSD which blocks it no longer uses via TRIM, so the controller can physically erase them in the background and leave them ready for future writes. Without TRIM, an SSD would end up erasing blocks on the fly, with the resulting performance loss.
Why this matters
Understanding that a file is a web of records and blocks, rather than a solid object, changes how you think about fragmentation, SSDs or backups. When your system says the disk is “full”, it means there are no free inodes or blocks left. When a drive corrupts and you “lose” a file, what usually breaks is precisely that invisible glue holding it together: the inode, the extent, or the journal entry.
Next time you save a document, remember: beneath the surface there is no box with your name on it, but a small metadata dossier and a pile of pieces that, thanks to decades of engineering, behave like a single coherent file.
