docker-internal: Fix typos

tutorial/4/filesystem-more.md

@@ -5,6 +5,6 @@
 
 Des expériences sont en cours pour essayer de faire un format
 d'archive pour les couches qui permettrait d'utiliser les conteneurs
-sans avoir eu besoin préalablement d'avoir télécharger le contenu des
+sans avoir eu besoin préalablement d'avoir téléchargé le contenu des
 couches :
 <https://github.com/containerd/stargz-snapshotter/blob/main/docs/estargz.md>

tutorial/4/filesystem.md

@@ -4,7 +4,7 @@ Systèmes de fichiers et couches
 ===============================
 
 Les images de conteneurs sont distribuées en couches, chaque couche contenant
-les différences apportée par rapport à la couche précédente : l'ajout d'un
+les différences apportées par rapport à la couche précédente : l'ajout d'un
 fichier, la suppression d'un dossier, ...
 
 L'intérêt principal est bien entendu d'optimiser l'espace de stockage, en
@@ -41,7 +41,7 @@ paquets, ou ajouter ses propres applications, documents, photos, ...
 Historiquement, le noyau Linux devait être *patché* pour supporter ce type de
 système de fichiers (que ce soit `unionfs` ou `aufs`, les deux principaux
 *patch* apportant cette fonctionnalité). Les systèmes BSD disposent d'une
-implémentation depuis au moins 1995 et c'est SunOS qui fût le premier OS à
+implémentation depuis au moins 1995 et c'est SunOS qui fut le premier OS à
 développer cette technique dès 1986 (pour un système de fichier appelé
 *Translucent File Service*). Pour Linux, il aura fallu attendre 2014 pour voir
 l'arrivée du système de fichier OverlayFS dans un noyau sans *patch*.
@@ -109,7 +109,7 @@ davantage de place au fil du temps et des modifications, que l'union.
 ## OverlayFS
 
 OverlayFS est arrivé dans le noyau 3.18, après de plus de 4 années de réécritures
-et d'amélioration structurelles, pour atteindre le niveau d'exigence et sans
+et d'améliorations structurelles, pour atteindre le niveau d'exigence et sans
 compromis nécessaire à son intégration dans le noyau officiel.
 
 ::::: {.question}
@@ -121,8 +121,8 @@ L'un des problèmes les plus délicats est de trouver une manière de représent
 les suppressions de fichiers et de dossiers : cela doit être un fichier valide
 (avec ou sans métadonnée) car il faut pouvoir stocker l'information
 concrètement. Dans de nombreuses implémentations, un fichier `.wh.<filename>`
-sert de *whiteout file*, ce qui peut créer des conflits avec des fichiers de
-l'utilisateur (ou réduire ses choix de noms de fichiers).
+sert de *whiteout file*, ce qui peut créer des conflits avec les noms des
+fichiers de l'utilisateur (ou réduire ses choix de noms de fichiers).
 
 Un problème similaire s'applique aux dossiers : est-ce qu'il faut supprimer
 chaque fichier contenu dans le dossier ou la simple présence d'un *opaque
@@ -136,11 +136,11 @@ fichiers.
 L'implémentation de `mmap(2)` est nécessairement un cauchemar : lorsqu'un
 fichier est modifié par deux processus qui le `mmap(2)`, on s'attend
 normalement à voir les modifications dans les deux processus, or le premier à
-faire une modification a créer un nouveau fichier dans la branche accessible en
-écriture. Il est ardu de réconcilier les pointeurs deux des processus.
+faire une modification crée un nouveau fichier dans la branche accessible en
+écriture. Il est alors ardu de réconcilier les pointeurs des deux processus.
 
 D'une manière similaire, il faut penser à la gestion des *hard links* : tous
-les pointeurs d'un contenu mis à jour devrait être modifié dans la couche en
+les pointeurs d'un contenu mis à jour devraient être modifiés dans la couche en
 écriture, cependant il n'y a pas d'index des pointeurs, il n'est donc pas
 facile de retrouver les fichiers à mettre à jour.
 
@@ -160,12 +160,12 @@ choix et différences : <https://lwn.net/Articles/325369/>,
 :::::
 
 Afin de satisfaire les contraintes d'intégration au noyau, le minimum de
-fonctionnalités ont été retenues : on ne peut notamment avoir qu'une seule
-couche en écriture, qui se positionne nécessairement au sommet, en
-superposition des autres. C'est de là que vient le nom du système de fichiers,
-puisqu'il s'agit davantage d'une superposition (*overlay*) d'un système de
-fichiers sur un autre, plutôt qu'une union de plusieurs systèmes aux politiques
-d'écritures potentiellement plus variées.
+fonctionnalités a été retenu : on ne peut notamment avoir qu'une seule couche
+en écriture, qui se positionne nécessairement au sommet, en superposition des
+autres. C'est de là que vient le nom du système de fichiers, puisqu'il s'agit
+davantage d'une superposition (*overlay*) d'un système de fichiers sur un
+autre, plutôt qu'une union de plusieurs systèmes aux politiques d'écritures
+potentiellement plus variées.
 
 
 ### Utilisation
@@ -196,7 +196,7 @@ mount -t overlay -olowerdir=/lower,upperdir=/upper,workdir=/work ignored /merged
 Le type à utiliser est `overlay`, avec les options `lowerdir` qui indique
 l'emplacement du/des dossiers à combiner en lecture seule (on les sépare par
 des `:` lorsqu'il y en a plusieurs), on indique également le répertoire
-contenant le système en lecture/écriture dans l'option `upperdir`, et on il
+contenant le système en lecture/écriture dans l'option `upperdir`, et il ne
 faut pas oublier l'option `workdir` un chemin sur la même partition que
 l'`upperdir`, qui doit être vide.
 
@@ -259,7 +259,7 @@ On peut également voir les dossiers utilisés en inspectant notre conteneur :
 ```
 </div>
 
-Si on teste avec une image avec plus de couches, on obtient davantage de
+Si on teste avec une image ayant plus de couches, on obtient davantage de
 `lowerdir`, un par couche. N'hésitez pas à faire la même série de commandes
 avec l'image `python` par exemple.
 
@@ -267,7 +267,7 @@ avec l'image `python` par exemple.
 ### Ajout de fichiers
 
 À ce stade, si nous regardons le contenu de notre dossier `upperdir`, nous
-pouvons remarqué que celui-ci est vide. C'est normal puisque nous n'avons apporté
+pouvons remarquer que celui-ci est vide. C'est normal puisque nous n'avons apporté
 aucune modification.
 
 Dans notre conteneur précédemment lancé, apportons une modification, en
@@ -387,7 +387,7 @@ monté conduisent à des résultats explicitement indéfinis.
 
 Le concept de *whiteout file*, comme on a pu le voir, diffère en fonction du
 système de fichiers. Il s'avère que même si l'OverlayFS a été intégré dans le
-noyau Linux après maintes péripéties, Docker, lorsqu'à été spécifié le format
+noyau Linux après maintes péripéties, Docker, lorsqu'a été spécifié le format
 des archives utilisées pour distribuer les couches, utilise aujourd'hui le
 format d'AuFS pour représenter les suppressions. Il est donc important de le
 voir également.