Improvements.

This commit is contained in:
Philippe Pittoli 2025-04-05 04:10:21 +02:00
parent 493deef217
commit b9242b0aa7

View file

@ -956,11 +956,11 @@ For example, a car can be both
.I elegant
and
.I fast .
The DODB API enables to retrieve data matching several tags\*[*].
.FOOTNOTE1
.B "Side note" .
The DODB API enables to retrieve data matching several tags.
Current DODB implementation performs the request of both tags then produces a list intersection.
The duration of the request would then be the addition of both tag requests and the duration of the intersection operation (plus an additional time span for memory management, depending on the list sizes).
.FOOTNOTE2
.
.
.SS Summary of the different databases and their use
@ -1091,7 +1091,7 @@ FYI, the service
.I netlib.re
uses DODB and since the database is fast enough, parallelism isn't required despite enabling several thousand requests per second in a virtual machine on a low-end hardware released almost two decades ago.
.FOOTNOTE2
Considering this swiftness, parallelism may seem as optional.
Considering this swiftness, the database part of the application isn't the performance bottleneck anymore, parallelism becomes optional for most instances.
The consistency property is a safety net for potentially defective software.
Always nice to have, but not entirely necessary, especially for document-oriented databases.
@ -1164,22 +1164,13 @@ The next paragraphs will give an idea of how filesystems work, the implied limit
Explaining the way filesystem work and their design is out of the scope of this document, so this part will be kept short for readability reasons.
.FOOTNOTE2
.
.
.SSS "How a filesystem works"
Filesystems designed for specific constraints, such as writing data on a compact disk\*[*] or providing a network filesystem, are out-of-scope of this document.
.FOOTNOTE1
A compact disk has specific constraints since the device will then only provide read-only access to the data, obviating the need for most of the complexity revolving around fragmentation, inode management and so on.
All storage devices have their own particularities, but regular hard drives and solid-state drives are the important ones for this discussion since filesystems have mostly been designed for them.
.FOOTNOTE2
The rest of this section will address more
.dq generic
filesystems\*[*] unless explicitely stated otherwise.
.FOOTNOTE1
Furthermore, the rich history behind filesystems is inherently related to the rich history of storage devices, this document is not supposed to be a survey on either of those.
Let's keep it short and simple.
.FOOTNOTE2
.
.TBD
talk about hard drives and SSDs.
Filesystems have similarities in their inner workings.
For instance, they have some
Most filesystems have some
.dq "special files"
called
.I inodes
@ -1200,7 +1191,20 @@ Since all files cannot be reasonably expected to be written in a continuous segm
Filesystems may enable to tweak the block size (related to the
.I "sector"
size of the storage device) either to reduce fragmentation and metadata (bigger block sizes to partitions with big files) or to avoid wasting space (smaller block sizes to partitions with a huge number of files under the size of a block).
.
Filesystems designed for specific constraints, such as writing data on a compact disk\*[*] or providing a network filesystem, are out-of-scope of this document.
.FOOTNOTE1
A compact disk has specific constraints since the device will then only provide read-only access to the data, obviating the need for most of the complexity revolving around fragmentation, inode management and so on.
All storage devices have their own particularities, but regular hard drives and solid-state drives are the important ones for this discussion since filesystems have mostly been designed for them.
.FOOTNOTE2
The rest of this section will address more
.dq generic
filesystems\*[*] unless explicitely stated otherwise.
.FOOTNOTE1
Furthermore, the rich history behind filesystems is inherently related to the rich history of storage devices, this document is not supposed to be a survey on either of those.
Let's keep it short and simple.
.FOOTNOTE2
.SSS "Objectives of a filesystem"
Filesystems share a (loosely) common set of objectives.