Introduction to filesystems.

This commit is contained in:
Philippe Pittoli 2025-04-05 15:54:38 +02:00
parent b9242b0aa7
commit a184fad40a

View file

@ -1165,10 +1165,40 @@ Explaining the way filesystem work and their design is out of the scope of this
.FOOTNOTE2
.
.
.SSS "How a filesystem works"
.SSS "Introduction to filesystems"
.
.TBD
talk about hard drives and SSDs.
Modern computing systems rely on storage devices to persistently retain data, even when power is turned off. The two most common types of storage media are Hard Disk Drives (HDDs) and Solid-State Drives (SSDs), each with distinct characteristics.
A filesystem is a software layer that structures data into files and directories, providing mechanisms for storage, retrieval, and management from a user perspective.
Thus, the filesystem abstracts the physical storage details, allowing users and applications to interact with data through logical operations (e.g., open, read, write) rather than dealing with low-level interactions with the storage devices.
The following paragraphs will explain the relation between filesystems, device drivers and storage devices.
From a logical perspective, HDDs and SSDs appear as linear arrays of fixed-size blocks (typically 512 bytes or 4 KiB), akin to a vast sequence of memory cells that can be read or written individually.
This abstraction allows higher-level software to interact with storage uniformly, regardless of the underlying hardware.
For example, a file system might request "block 0x42A1" without needing to know whether it resides on an HDDs magnetic platter or an SSDs NAND chip.
However, the physical reality of these devices is far more complex.
HDDs store data on spinning platters divided into tracks and sectors, with read/write heads moving mechanically to access specific locations.
This introduces latency due to seek times and rotational delays.
Meanwhile, SSDs use arrays of flash memory cells organized into pages and blocks, with no moving parts but constrained by erase-before-write cycles and wear-leveling requirements.
The operating systems driver layer bridges this gap: it translates logical block requests into device-specific commands.
For HDDs, this might involve calculating cylinder-head-sector (CHS) geometries; for SSDs, it could mean remapping blocks to distribute wear.
Crucially, this complexity is hidden from the file system, which operates on the logical block abstraction.
However, raw storage devices and device drivers cannot organize data efficiently all by themselves.
That's why a filesystem may be designed to reduce seek times in a hard drive, in this case it will try to distribute data in a
.dq packed
way that minimises the disk's head movements.
Thus, filesystems, drivers and devices are intertwined and share responsability for the performances and the device durability even though they work at different levels.
The file system builds upon logical blocks of data, adding structure to raw blocks that brings some semantics.
It manages:
.STARTBULLET
.BULLET organization: mapping files and directories to sequences of blocks;
.BULLET metadata: tracking ownership, permissions, and block allocation;
.BULLET optimization: minimizing HDD seek times or SSD wear.
.ENDBULLET
Most filesystems have some
.dq "special files"