Introduction to filesystems.
This commit is contained in:
parent
b9242b0aa7
commit
a184fad40a
1 changed files with 33 additions and 3 deletions
|
@ -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 HDD’s magnetic platter or an SSD’s 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 system’s 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"
|
||||
|
|
Loading…
Add table
Reference in a new issue