More filesystem explanations.
This commit is contained in:
parent
a184fad40a
commit
a9cc12e096
2 changed files with 52 additions and 6 deletions
33
paper/filesystem-driver-device.pic
Normal file
33
paper/filesystem-driver-device.pic
Normal file
|
@ -0,0 +1,33 @@
|
|||
h=0.7
|
||||
w=8.0
|
||||
.gcolor white
|
||||
box ht h wid w
|
||||
.gcolor
|
||||
move
|
||||
|
||||
w=1.7
|
||||
|
||||
FS: arrow at last box .w + (0.4, 0)
|
||||
DRI: arrow at last arrow .e + (w, 0)
|
||||
DEV: arrow at last arrow .e + (w, 0)
|
||||
|
||||
.ps +4
|
||||
TXTFS: "filesystem" at 1/2 between FS.e and DRI.w
|
||||
TXTDRI: "driver" at 1/2 between DRI.e and DEV.w
|
||||
TXTDEV: "device" at DEV.e + (w/2,0)
|
||||
.ps
|
||||
|
||||
# subtexts
|
||||
subtexth = 0.2
|
||||
"(user interface," at TXTFS + (0, -subtexth)
|
||||
"permissions," at Here + (0, -0.15)
|
||||
"file to logical block addresses," at Here + (0, -0.15)
|
||||
"some optimizations)" at Here + (0, -0.15)
|
||||
"(logical to physical" at TXTDRI + (0, -subtexth)
|
||||
"block addresses," at Here + (0, -0.15)
|
||||
"some optimizations)" at Here + (0, -0.15)
|
||||
"(actually stores data)" at TXTDEV + (0, -subtexth)
|
||||
|
||||
"files and" "directories" at 1/2 between FS.e and FS.w + (0, h)
|
||||
"logical blocks" "ex: 0x4b1f" at 1/2 between DRI.e and DRI.w + (0, h)
|
||||
"physical blocks" "ex: Cylinder 12," "Head 3, Sector 33" at 1/2 between DEV.e and DEV.w + (0, h)
|
|
@ -1167,13 +1167,14 @@ Explaining the way filesystem work and their design is out of the scope of this
|
|||
.
|
||||
.SSS "Introduction to filesystems"
|
||||
.
|
||||
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.
|
||||
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.
|
||||
This abstraction allows higher-level software (filesystems) 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.
|
||||
|
@ -1186,13 +1187,14 @@ For HDDs, this might involve calculating cylinder-head-sector (CHS) geometries;
|
|||
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
|
||||
Filesystems are designed to overcome some physical limitations of the devices, for example to reduce seek times in a hard drive by distributing data in a
|
||||
.dq packed
|
||||
way that minimises the disk's head movements.
|
||||
way that minimizes 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:
|
||||
The file system builds upon logical blocks of data, adding structure and hierarchy (files and directories) to raw blocks.
|
||||
From the user perspective, the file system brings some semantics.
|
||||
A filesystem manages:
|
||||
|
||||
.STARTBULLET
|
||||
.BULLET organization: mapping files and directories to sequences of blocks;
|
||||
|
@ -1200,6 +1202,17 @@ It manages:
|
|||
.BULLET optimization: minimizing HDD seek times or SSD wear.
|
||||
.ENDBULLET
|
||||
|
||||
The following figure summarizes the relations between filesystems, drivers and devices.
|
||||
|
||||
.PS
|
||||
reset
|
||||
copy "filesystem-driver-device.pic"
|
||||
.PE
|
||||
.QP
|
||||
This figure is a simplification, real-life device drivers do not use Cylinder-Head-Sector (CHS) scheme anymore.
|
||||
The complexity of handling actual head movements shifted towards the devices.
|
||||
.QE
|
||||
|
||||
Most filesystems have some
|
||||
.dq "special files"
|
||||
called
|
||||
|
|
Loading…
Add table
Reference in a new issue