WIP: advancing second part of filesystems

9.filesystems/02_Systemes_fichiers_strategies_alloc.md

@@ -237,42 +237,49 @@ Métriques principales:
 
 <div style="font-size:0.8em">
 
-Soit le FS de type FAT suivant :
+Soit le FS de type FAT suivant : <!-- .element: style="text-align:left;margin:0px" -->
 
 - Le FS comporte 1'000 blocs de données
 - Taille des blocs de données : 4 KB
-- Chaque entrée dans la FAT est codée sur 16 bits
-  - une valeur est réservée pour représenter la EOC (*End Of Chain*)
+- Chaque entrée dans la FAT est codée sur 16 bits (une valeur est réservée pour représenter la EOC - *End Of Chain*)
 
 </div>
 
 **Questions**
 
-1. Quelle est la taille de la FAT en bytes pour ce FS ? \
-`$1000*(16 bits) = 2000$` bytes <!-- .element: class="fragment" data-fragment-index="0" -->
+1. Quelle est la taille de la FAT en bytes pour ce FS ?
+ `$1000*(16 bits) = 2000$ bytes` <!-- .element: class="fragment" data-fragment-index="1" -->
 
 1. Quelle est la taille de fichier maximum supportée pour ce FS (en bytes, KB et MB) ? \
-`$1000*4096 = 4096000$` bytes, `$4000$` KB, `$3.9`$ MB <!-- .element: class="fragment" data-fragment-index="0" -->
+`$1000*4096 = 4096000$ bytes, $4000$ KB, $3.9$ MB` <!-- .element: class="fragment" data-fragment-index="2" -->
 
 1. Combien de blocs de données cette FAT pourrait-elle gérer au maximum théoriquement ? \
-`$(2^{16})-1$ = 65535` <!-- .element: class="fragment" data-fragment-index="0" -->
+`$(2^{16})-1 = 65535$ blocs` <!-- .element: class="fragment" data-fragment-index="3" -->
 
 
 --
 
 ## 2.b. Allocation par FAT : synthèse
 
-- \textbf{\textcolor{mygreen}{Avantages}}
-  - relativement facile à implémenter
-  - les fichiers peuvent facilement grandir (tant qu'il y a de l'espace dans la FAT)
-  - accès aléatoire rapide
-  - pas de fragmentation externe
+<fieldset class="OK">
+<legend>Avantages</legend>
 
-- \textbf{\textcolor{myred}{Inconvénients}}
-  - accès séquentiel lent si les blocs ne sont pas contigus (HDD uniquement)
-  - *overhead* important pour le stockage de la FAT (disque et RAM), en particulier avec un grand nombre de clusters
-  - la FAT doit être chargée en RAM (sinon performances catastrophiques)
-  - fragmentation interne lorsque taille fichier < taille bloc
+- relativement facile à implémenter
+- les fichiers peuvent facilement grandir (tant qu'il y a de l'espace dans la FAT)
+- accès aléatoire rapide
+- pas de fragmentation externe
+
+</fieldset>
+<p></p>
+<fieldset class="warning fragment">
+<legend>Inconvénients</legend>
+
+- accès séquentiel lent si les blocs ne sont pas contigus (HDD uniquement)
+- *overhead* important pour le stockage de la FAT (disque et RAM), en particulier avec un grand nombre de clusters
+- la FAT doit être chargée en RAM (sinon performances catastrophiques)
+- fragmentation interne lorsque taille fichier < taille bloc
+
+</fieldset>
 
 --
 
@@ -283,47 +290,39 @@ Soit le FS de type FAT suivant :
   - les métadonnées du fichier
   - la liste des pointeurs vers les blocs de données
 
-\vspace{.3cm}
-
-\centering
-![](images/indexed_alloc.png){ width=50% }
+![](images/indexed_alloc.png) <!-- .element width="45%" -->
 
 --
 
 ## 3.b. Allocation indexée multi-niveau
 
-\small
-
 - L'inode stocke pointeurs directs, indirects, doublement indirects, etc.
 - Utilisé par tous les FS dans les systèmes UNIX : minix-fs, ext2, ext3, etc.
 
-\centering
-![](images/multi_indexed_alloc.png){ width=90% }
+![](images/multi_indexed_alloc.png) <!-- .element width="85%" -->
 
 --
 
-## 3.b Allocation indexée multi-niveau : exemple
+## 3.b. Alloc. indexée multi-niv. : exemple
 
-\small
+<div style="font-size:0.8em">
 
-Soit le FS de type indexé multi-niveau suivant :
+Soit le FS de type indexé multi-niveau suivant : <!-- .element: style="text-align:left;margin:0px" -->
 
 - Un inode fait 64 bytes
 - Un inode contient 8 pointeurs directs, 2 pointeurs indirects et 1 pointeur doublement indirect
 - Un pointeur de bloc est stocké sur 16 bits
 - Taille des blocs de données : 1 KB (1024 bytes)
 
-::: incremental
+</div>
 
 **Questions**
 
-1. Combien peut-on stocker de pointeurs par bloc\ ?
-   - \footnotesize \textcolor{mygreen}{$1024/2$ = 512}
-
-1. Quelle est la taille de fichier maximum supportée pour ce FS (en bytes, KB et MB)\ ?
-   - \footnotesize \textcolor{mygreen}{$8*1024 + (512*1024)*2 + (512^2)*1024$ = 269492224 bytes, 263176 KB, 257 MB }
+1. Combien peut-on stocker de pointeurs par bloc ? \
+   `$1024/2 = 512$` <!-- .element: class="fragment" -->
 
-:::
+2. Quelle est la taille de fichier maximum supportée pour ce FS (en bytes, KB et MB) ? \
+  `$8*1024 + (512*1024)*2 + (512^2)*1024 = 269492224$ bytes, $263176$ KB, $257$ MB` <!-- .element: class="fragment" -->
 
 <!--
 1. Combien peut-on stocker d'inodes par bloc\ ?
@@ -334,17 +333,25 @@ Soit le FS de type indexé multi-niveau suivant :
 
 ## 3.b. Allocation indexée : synthèse
 
-- \textbf{\textcolor{mygreen}{Avantages}}
-  - relativement facile à implémenter
-  - les fichiers peuvent facilement grandir (tant qu'il y a des pointeurs libres)
-  - accès aléatoire rapide
-  - pas de fragmentation externe
+<fieldset class="OK">
+<legend>Avantages</legend>
 
-- \textbf{\textcolor{myred}{Inconvénients}}
-  - *overhead* de stockage pour les pointeurs
-  - l'accès rapide nécessite l'allocation de blocs contigus (HDD uniquement)
-    - sinon, accès potentiellement lent
-  - fragmentation interne lorsque taille fichier < taille bloc
+- relativement facile à implémenter
+- les fichiers peuvent facilement grandir (tant qu'il y a des pointeurs libres)
+- accès aléatoire rapide
+- pas de fragmentation externe
+
+</fieldset>
+<p></p>
+<fieldset class="warning fragment">
+<legend>Inconvénients</legend>
+
+- *overhead* de stockage pour les pointeurs
+- l'accès rapide nécessite l'allocation de blocs contigus (HDD uniquement)
+  - sinon, accès potentiellement lent
+- fragmentation interne lorsque taille fichier < taille bloc
+
+</fieldset>
 
 --