From 80f444b32f3ba1f898eac92a2e926620b9dbb1ac Mon Sep 17 00:00:00 2001
From: Guillaume Chanel <Guillaume.Chanel@unige.ch>
Date: Wed, 9 Oct 2024 15:51:59 +0200
Subject: [PATCH] update minix and implementation
---
9.filesystems/04_Systemes_fichiers_minix.md | 87 +++++++++++++++----
.../05_Systemes_fichiers_implementation.md | 4 +-
2 files changed, 75 insertions(+), 16 deletions(-)
diff --git a/9.filesystems/04_Systemes_fichiers_minix.md b/9.filesystems/04_Systemes_fichiers_minix.md
index 9478668..2882e00 100644
--- a/9.filesystems/04_Systemes_fichiers_minix.md
+++ b/9.filesystems/04_Systemes_fichiers_minix.md
@@ -29,10 +29,16 @@
- Les premières versions du noyau Linux (1992) utilisaient MINIX-fs comme FS
- 1992 : Rémy Card implémente ext (Extended Filesystem) pour remplacer MINIX-fs
- ext est basé sur une structure similaire à MINIX-fs
-- 1993 : Rémy Card publie ext2
-- 2001 : Theodore Ts'o et d'autres publient ext3
+- 1993 : Rémy Card publie ext2 (amélioration de performances)
+- 2001 : Theodore Ts'o et d'autres publient ext3 (ajout de journalisation)
- 2006 : la version instable de ext4 est publiée
-- 2008 : la version stable de ext4 est publiée
+- 2008 : la version stable de ext4 est publiée (amélioration de performances et augmentations des limites de tailles)
+
+<aside class="notes">
+
+Tailles augmentée pour ext4: fichiers, volumes et répertoires
+
+</aside>
--
@@ -44,6 +50,12 @@
- variante avec noms de fichiers de 14 caractères max (superblock magic value `0x137F`)
- variante avec noms de fichiers de 30 caractères max (superblock magic value `0x138F`)
+<aside class="notes">
+
+magic value: une valeure qui fait partie du super bloc
+
+</aside>
+
--
## Comparaison MINIX-fs et ext2/3/4
@@ -82,7 +94,7 @@ struct minix_inode {
u16 i_mode; // file type and permissions for file
u16 i_uid; // user id
u32 i_size; // file size in bytes
- u32 i_time; // inode time
+ u32 i_time; // inode modification time
u8 i_gid; // group id
u8 i_nlinks; // number of dir entry pointing to
// this inode
@@ -95,6 +107,14 @@ struct minix_inode {
- **Important** : structure sur disque stockée selon l'ordre *little-endian*
- Taille d'un inode en bytes ?
+<aside class="notes">
+
+On calcule, d'après la structure minix_inode, que sur Minix un inode est 32 octets (bytes).
+
+1024 octets (taille du bloc) / 32 octets (taille d'un inode) = 32 inodes par bloc
+
+</aside>
+
--
## Structure du mode du fichier
@@ -177,7 +197,7 @@ struct minix_super_block {
// need 6848 bits
// -> 1 block = 8192 bits
u16 s_zmap_blocks = 3; // data blocks bitmap size in blocks
- // need 20480 bits -> 3 blocks = 8192*3 bits
+ // need 20480 - 220 bits -> 3 blocks = 8192*3 bits
u16 s_firstdatazone = 220; // index of first data block
u16 s_log_zone_size = 0; // block size = 1024*2^s_log_zone_size
// = 1024*2^0 = 1024
@@ -191,6 +211,32 @@ struct minix_super_block {
<small>1: permet d'arrondir au prochain multiple de la taille d'un inode</small>
+<aside class="notes">
+
+Le calcul pour arriver à 220 comme premier bloc de données (s_firstdatazone) est le suivant:
+
+Bloc 0 pour le superbloc
+
+6848 inodes / 32 inodes par bloc = 214 blocs pour la table d'inodes
+
+1 bloc pour la bitmap des inodes
+
+3 blocs pour la bitmap des zones (blocs de données)
+
+Total : 1 + 214 + 1 + 3 = 219 blocs
+
+Le calcul pour arriver à 268966912 octets pour la taille max d'un fichier (s_max_size) est le suivant:
+
+7 pointeurs directs : 7 * 1024 = 7168 octets -- Les 7 premiers pointeurs de l'inode pointent directement vers des blocs de données.
+
+1 pointeur d'indirection simple : 512 * 1024 = 524288 octets -- Un bloc d'indirection simple contient 512 pointeurs (1024 / 2, car chaque pointeur fait 2 octets).
+
+1 pointeur d'indirection double : 512 * 512 * 1024 = 268435456 octets -- Le bloc d'indirection double pointe vers 512 blocs d'indirection simple, chacun pointant vers 512 blocs de données.
+
+Total: 1024 * 7 + 512 * 1024 + 512 * 512 * 1024 = 268966912
+
+</aside>
+
--
## Exemple de superbloc
@@ -236,7 +282,7 @@ struct minix_inode {
u8 i_gid = 0; // 0 = root
u8 i_nlinks = 8; // 8 dir entries point to
// this inode
- u16 i_zone[7] = {220, 0, 0, 0, 0, 0, 0 }; // 1 data block
+ u16 i_zone[7] = {220, 0, 0, 0, 0, 0, 0 }; // 1 data block ⚠️ index 0 = superbloc
u16 i_indir_zone = 0; // no indirect block
u16 i_dbl_indir_zone = 0; // no double indirect block
};
@@ -278,6 +324,16 @@ struct minix_inode {
</div>
+<aside class="notes">
+
+00 00 79 6F 00 00 00 00 00 00 00 00 00 00 00 00 ..yo............
+
+Les deux premiers octets (00 00) indiquent un numéro d'inode 0, ce qui signifie que cette entrée est inutilisée. Les deux octets suivants (79 6F) correspondent aux caractères ASCII "yo".
+
+Cette entrée était donc utilisée auparavant pour un fichier ou un répertoire appelé "yo". Lorsque l'entrée a été supprimée, le numéro d'inode a été mis à 0, mais le nom n'a pas été effacé.
+
+</aside>
+
--
## Exemple d'inode - fichier répertoire
@@ -326,7 +382,7 @@ struct minix_inode {
<div style="font-size: 0.8em">
- Le nom `.` (0x2E) pointe sur l'inode 2 (lui même)
-- Le nom `.` (0x2E2E) pointe sur le répertoire parent, l'inode 1 (la racine)
+- Le nom `..` (0x2E2E) pointe sur le répertoire parent, l'inode 1 (la racine)
- Il y a 2 répertoires : `linux` (inode 0x36C) et `system` (inode 0x9)
- Il y a 2 fichiers : `hello.c` (inode 0xB) et `.bash_login` (inode 0xE)
- Il y a 4 `dir_entry` inutilisées (inodes à 0)
@@ -359,7 +415,7 @@ struct minix_inode {
## Exemple de bloc de données - contenu fichier régulier
-Contenu du 1er bloc de données référencé par l'inode 11\
+Contenu du 1er bloc de données référencé par l'inode 11 (0xB)
- bloc 583 (offset = 583*1024 = 0x91C00)
@@ -384,7 +440,7 @@ Contenu du 1er bloc de données référencé par l'inode 11\
## Exemple d'inode - fichier régulier
-Contenu de l'inode 16
+Contenu de l'inode 16 (0x10)
```c
struct minix_inode {
@@ -407,7 +463,7 @@ struct minix_inode {
## Exemple de bloc de données - contenu fichier régulier
-Contenu du bloc indirect référencé par l'inode 11\
+Contenu du bloc indirect référencé par l'inode 16 (0x10)
- bloc 595 (offset = 595*1024 = 0x94C00)
@@ -437,9 +493,9 @@ Contenu du bloc indirect référencé par l'inode 11\
- Le nombre total d'inodes pouvant être créés dans le FS est indiqué par le champs `ninodes` du superbloc
- La table des inodes possède `ninodes` entrées
- Le premier inode de la table (à l'indice 0) est l'inode 1, il n'y a donc pas d'inode 0 !
-- **Attention** : le bit 0 du bitmap indique l'état de l'inode 0 !
- - le bit 0 est toujours à 1 (utilisé), bien que l'inode 0 n'existe pas
- - un FS vide aura donc 2 bits à 1 dans le bitmap\ : le bit 0 (inode 0) et le bit 1 (inode 1 = répertoire racine)
+- **Attention** :
+ - le bit 0 du bitmap indique l'"état" de l'inode 0 ! le bit 0 est toujours à 1 (utilisé), bien que l'inode 0 n'existe pas
+ - un FS vide aura donc 2 bits à 1 dans le bitmap: le bit 0 (inode 0) et le bit 1 (inode 1 = répertoire racine)
</div>
<br>
@@ -461,8 +517,9 @@ Contenu du bloc indirect référencé par l'inode 11\
- Les n° de blocs dans l'inode sont relatifs au début du FS
- Le bitmap des blocs de données indique uniquement l'état des **blocs de données** utilisés (donc pas superbloc, bitmaps, etc.)
-- **Attention** : le bit 0 du bitmap des blocs de données est à **ignorer** !
- - il est toujours à 1 et ne représente aucun bloc de données
+- **Attention** :
+ - le bit 0 du bitmap des blocs de données est à **ignorer** !
+ - Il est toujours à 1 et ne représente aucun bloc de données
- le bit 1 du bitmap correspond au bloc `firstdatazone` indiqué dans le superbloc
- il correspond donc au premier bloc de données
diff --git a/9.filesystems/05_Systemes_fichiers_implementation.md b/9.filesystems/05_Systemes_fichiers_implementation.md
index cae8588..8a15357 100644
--- a/9.filesystems/05_Systemes_fichiers_implementation.md
+++ b/9.filesystems/05_Systemes_fichiers_implementation.md
@@ -155,7 +155,9 @@ indirect, pas l'indice 8
- Nombre de blocs adressables avec une seule indirection : 4
- Nombre de blocs adressables avec une double indirection : 4*4
-<!-- .element width="70%" -->
+<!-- .element width="65%" -->
+
+<small> ⚠️ ici les blocs sont indéxés logiquement en réalité c'est leur numéro physique qui est présents dans les tableaux de zone
--
--
GitLab