update minix and implementation

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
 

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
 
-![](images/bmap_example.png)<!-- .element width="70%" -->
+![](images/bmap_example.png)<!-- .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
 
 --