From e91eac4b30c357e2892f19c74e3b8b09398da204 Mon Sep 17 00:00:00 2001
From: Guillaume Chanel <Guillaume.Chanel@unige.ch>
Date: Mon, 26 Aug 2024 11:45:55 +0200
Subject: [PATCH] Add part3 on disk structure
---
.../03_Systemes_fichiers_struct_disque.md | 287 ++++++++----------
9.filesystems/Ressources.md | 8 +-
9.filesystems/index.html | 2 +-
3 files changed, 130 insertions(+), 167 deletions(-)
diff --git a/9.filesystems/03_Systemes_fichiers_struct_disque.md b/9.filesystems/03_Systemes_fichiers_struct_disque.md
index 332a694..d7462f1 100644
--- a/9.filesystems/03_Systemes_fichiers_struct_disque.md
+++ b/9.filesystems/03_Systemes_fichiers_struct_disque.md
@@ -1,24 +1,7 @@
----
-author: Florent Gluck - Florent.Gluck@hesge.ch
+# Structure sur disque
-title: Systèmes de fichiers - Structure sur disque
+--
-date: \vspace{.5cm} \footnotesize \today
-
-institute: \vspace{0.5cm} \tiny \textsuperscript{*}Remerciements à Mickaël Hoerdt
-
-pandoc-latex-fontsize:
- - classes: [tiny]
- size: tiny
- - classes: [verysmall]
- size: scriptsize
- - classes: [small]
- size: footnotesize
- - classes: [huge, important]
- size: huge
----
-
-[//]: # ----------------------------------------------------------------
## Concepts clés d'un système de fichiers stocké
1. Quelles sont les structures de données stockées sur le disque qui organisent les méta-données et le contenu des fichiers ?
@@ -28,107 +11,100 @@ pandoc-latex-fontsize:
1. Quelles sont les interfaces d'accès au système de fichiers (FS) ?
- comment est-ce que le système associe p.ex. `open()`, `read()` et `write()` aux points 1 et 2 ?
-[//]: # ----------------------------------------------------------------
+--
+
## Exemple de structure simple d'un FS
-\small
Soit un FS constitué de 64 blocs
-\vspace{.2cm}
-
-\centering
-{ width=100% }
+
+--
-[//]: # ----------------------------------------------------------------
## Exemple de structure simple d'un FS
-\small
Le bloc 0 est réservé : contient potentiellement le secteur de boot et la table de partitions
-\vspace{.2cm}
+
-\centering
-{ width=100% }
+--
-[//]: # ----------------------------------------------------------------
## Blocs de données
-\small
Pour stocker des données il est préférable que la majorité des blocs soient réservés pour cela (blocs de données)
-\vspace{.2cm}
+
-\centering
-{ width=100% }
+--
-[//]: # ----------------------------------------------------------------
## Allocation des blocs de données
-\footnotesize
+<div style="font-size:0.8em">
+
- Un tableau de bits indique quels blocs de données sont disponibles/utilisés
- Appelé **bitmap de blocs**
- Contient autant de bits qu'il y a de blocs de données
-\centering
-{ width=100% }
+</div>
-[//]: # ----------------------------------------------------------------
-## Exemple de bitmap pour les blocs de données
+
+
+--
+
+### Exemple de bitmap pour les blocs de données
-\small
- Soit 3 blocs de données utilisés : 2, 3 et 6
- Bitmap contient : 0,0,1,1,0,0,1,0,0,...
-\centering
-{ width=100% }
+
+
+--
-[//]: # ----------------------------------------------------------------
## Allocation des blocs de données
- Un bitmap pour allouer les blocs n'est qu'un exemple de structure d'allocation
- D'autres structures sont possibles : listes, arbres, etc.
- On peut donc allouer/libérer des blocs de données, mais on veut aussi associer des blocs à un/des fichiers
-[//]: # ----------------------------------------------------------------
-## Association blocs de données $\leftrightarrow$ fichiers
+--
+
+### Association blocs de données `$\leftrightarrow$` fichiers
-\small
- C'est la fonction principale des **inodes**
- Les inodes contiennent également les méta-données des fichiers
-\centering
-{ width=100% }
-[//]: # ----------------------------------------------------------------
+
+
+--
+
## Inodes
- La taille d'un inode est fixe pour un FS donné
-- Le inodes sont stockés de manière **contigüe** au début du FS
- - appelé la **table d'inodes**
+- Le inodes sont stockés de manière **contigüe** au début du FS dans la **table d'inodes**
- Selon le FS, la taille varie (typiquement divise la taille d'un secteur, 512 bytes)
- La taille d'un inode est définie à la création du FS
- Un petit FS (= faible nombre de blocs) aura typiquement une taille d'inode inférieure à un grand FS
- Soit des blocs de 4 KB et une taille d'inode de 128 bytes
- - combien d'inodes par bloc ?
+ - combien d'inodes par bloc ? \
+`$4096$ bytes / $128$ bytes $= 32$ inodes par bloc` <!-- .element class="fragment" -->
+
+
+--
-[//]: # ----------------------------------------------------------------
## Table d'inodes
-\small
Exemple d'une table d'inodes utilisant 2 blocs
- Taille de bloc : 2 KB
- Taille d'inode : 128 bytes
-**\textcolor{myred}{Les inodes sont indexés à 1}**
+**Les inodes sont indexés à 1**
-\vspace{.3cm}
+ <!-- .element width="70%" -->
-\centering
-{ width=75% }
+--
-[//]: # ----------------------------------------------------------------
## Relation fichier $\leftrightarrow$ inode
- Chaque fichier est associé **exactement** à 1 inode
@@ -136,117 +112,117 @@ Exemple d'une table d'inodes utilisant 2 blocs
- Des FS différents peuvent utiliser les mêmes n° d'inodes
- Le n° d'inode d'un fichier supprimé est réutilisé par le FS
-[//]: # ----------------------------------------------------------------
+--
+
## Historique du nom "inode"
-"In truth, I don't know either. It was just a term that we started to use. ‘Index’ is my best guess, because of the
-slightly unusual file system structure that stored the access information of files as a flat array on the disk..."
-\vspace{.5cm}
+> In truth, I don't know either. It was just a term that we started to use. ‘Index’ is my best guess, because of the slightly unusual file system structure that stored the access information of files as a flat array on the disk...
-Dennis Ritchie[^1]
+*Dennis Ritchie*<sup>1</sup>
-[^1]: \footnotesize Un des deux principaux créateurs d'UNIX, l'autre étant Ken Thompson
+<small>1: Un des deux principaux créateurs d'UNIX, l'autre étant Ken Thompson</small>
+
+--
-[//]: # ----------------------------------------------------------------
## Structure d'un inode
-\small
+<div style="font-size: 0.7em">
+
Structure typique, mais qui peut varier en fonction du FS :
-\scriptsize
-
-**Champ** **Description**
--------------- -----------------------------
-`type` \textcolor{myblue}{Fichier}, \textcolor{myorange}{répertoire}, device, lien, etc.
-`uid` UID du propriétaire
-`gid` GID du propriétaire
-`rwx` Permissions (droits d'accès)
-`size` Taille en bytes
-`time` Date du dernier accès
-`n_links` Nombre de liens/chemins d'accès vers l'inode
-`direct[N]` Pointeurs directs vers les blocs du contenu du
- fichier, **dans l'ordre**
-`indir[M]` Pointeurs indirects vers les blocs du contenu
- du fichier, **dans l'ordre**
-`dbl_indir[P]` Pointeurs doublement indirects vers les blocs
- du contenu du fichier, **dans l'ordre**
-
-\vspace{-.3cm}
+Champ | Description
+------------ | -----------------------------
+`type` | **Fichier**, **répertoire**, device, lien, etc.
+`uid` | UID du propriétaire
+`gid` | GID du propriétaire
+`rwx` | Permissions (droits d'accès)
+`size` | Taille en bytes
+`time` | Date du dernier accès
+`n_links` | Nombre de liens/chemins d'accès vers l'inode
+`direct[N]` | Pointeurs directs vers les blocs du contenu du fichier, **dans l'ordre**
+`indir[M]` | Pointeurs indirects vers les blocs du contenu du fichier, **dans l'ordre**
+`dbl_indir[P]`| Pointeurs doublement indirects vers les blocs du contenu du fichier, **dans l'ordre**
+
Une valeur de 0 dans les n° indique une entrée non-utilisée
-[//]: # ----------------------------------------------------------------
+</div>
+
+--
+
## Allocation des blocs de données dans un inode
-\small
Exemple avec : 10 pointeurs directs, 1 pointeur indirect, 1 pointeur doublement indirect et 1 pointeur triplement indirect
-\vspace{.3cm}
+ <!-- .element width="70%" -->
-\centering
-{ width=90% }
+--
-[//]: # ----------------------------------------------------------------
## Contenu des fichiers
-- Un fichier de **type \textcolor{myblue}{fichier}** est un fichier habituel dont les données (contenu) peuvent être :
+- Un **fichier régulier** est un fichier habituel dont les données (contenu) peuvent être :
- du texte si c'est un fichier texte
- des données d'image si c'est un fichier png
- des données audio si c'est un fichier flac
- etc.
-- Un fichier de **type \textcolor{myorange}{répertoire}** (*directory*) est un fichier qui contient des entrées de répertoires (*directory entries*)
+- Un fichier de **type répertoire** (*directory*) est un fichier qui contient des entrées de répertoires (*directory entries*)
+
+--
-[//]: # ----------------------------------------------------------------
## Entrée de répertoire
- Une entrée de répertoire associe simplement un nom à un inode
- Structure d'une entrée de répertoire (`dir_entry`) :
-**Champ** **Description**
--------------- -----------------------------
-`inode` numéro d'inode du fichier
-`name` nom associé à cet inode (fichier)
+Champ | Description
+------------- | -----------------------------
+`inode` | numéro d'inode du fichier
+`name` | nom associé à cet inode (fichier)
+
+<br>
+
+<fieldset class="warning">
-\vspace{.3cm}
-**\textcolor{myred}{Un fichier n'est donc pas caractérisé par son nom, mais par son inode !}**
+Un fichier n'est donc pas caractérisé par son nom, mais par son inode !
+
+</fieldset>
+
+--
-[//]: # ----------------------------------------------------------------
## Contenu d'un répertoire
-\small
-- Le contenu d'un fichier de type **\textcolor{myorange}{répertoire}** contient des entrées de répertoires
+- Le contenu d'un fichier de type **répertoire** contient des entrées de répertoires
- Par convention, dans la plupart des FS, l'inode n° 1 est le répertoire racine du FS : `/`
-\vspace{.2cm}
+ <!-- .element width="80%" -->
-\centering
-{ width=100% }
+--
-[//]: # ----------------------------------------------------------------
## Liens symboliques
-\small
-
- En Anglais : *soft links* ou *symbolic links*
- Un fichier de type **lien symbolique** a comme contenu (1 seul bloc de donnée) une chaîne de caractères représentant le chemin de destination du lien
- Lors de l'analyse d'un chemin d'accès, si le système rencontre un lien symbolique, alors son contenu est concaténé avec le chemin déjà parcouru
- `ln -s` permet de créer un lien symbolique
- Exemple : créé le lien symbolique `pipo.c` vers `code/src/prog.c` :
- ```{.shell .verysmall}
- ln -s code/src/prog.c pipo.c
+
+ ```bash
+ $ ln -s code/src/prog.c pipo.c
```
-[//]: # ----------------------------------------------------------------
+--
+
## Liens symboliques : considérations importantes
- Un lien symbolique peut pointer vers un fichier ou un répertoire
- Un lien symbolique peut traverser les FS
- il est possible de créer un lien symbolique X sur le FS1 qui pointe vers le fichier Y sur le FS2
-- Si la destination d'un lien symbolique est déplacée ou supprimée, le lien symbolique devient alors invalide\ !
+- Si la destination d'un lien symbolique est déplacée ou supprimée, le lien symbolique devient alors invalide !
+
+--
-[//]: # ----------------------------------------------------------------
## Liens durs
- En Anglais : *hard links*
@@ -254,51 +230,55 @@ Exemple avec : 10 pointeurs directs, 1 pointeur indirect, 1 pointeur doublement
- En d'autres termes, il s'agit simplement d'un nom supplémentaire pointant vers le même inode
- `ln` permet de créer un lien dur
- Exemple : créé le lien dur `pipo.c` vers `code/src/prog.c` :
- ```{.shell .verysmall}
- ln code/src/prog.c pipo.c
+
+ ```.bash
+ $ ln code/src/prog.c pipo.c
```
-[//]: # ----------------------------------------------------------------
+--
+
## Liens durs : considérations importantes
- Un lien dur ne peut pas pointer vers un répertoire
-- Un lien dur ne peut pas traverser les FS car un numéro d'inode est seulement unique à un FS\ !
+- Un lien dur ne peut pas traverser les FS car un numéro d'inode est seulement unique à un FS !
- La valeur `Links` affichée par la commande `stat` indique le nombre de `dir_entry` pointant sur le fichier (inode)
-- \textcolor{myred}{Un fichier (inode) n'est \textbf{réellement supprimé} que lorsque le dernier \texttt{dir\_entry} (lien dur) pointant dessus est supprimée !}
- - aussi, si un descripteur de fichier ouvert référence ce fichier (inode), alors le fichier ne sera supprimé que lorsque le dernier descripteur sera fermé
+- <!-- .element style="color:red" --> Un fichier (inode) n'est **réellement supprimé** que lorsque le dernier *dir_entry* (lien dur) pointant dessus est supprimée !
+ - <!-- .element style="color:black"--> aussi, si un descripteur de fichier ouvert référence ce fichier (inode), alors le fichier ne sera supprimé que lorsque le dernier descripteur sera fermé
- Les liens durs (ou `dir_entry`) sont donc simplement des références vers un inode (fichier)
-[//]: # ----------------------------------------------------------------
+--
+
## Allocation des inodes
-\small
- Similairement à l'allocation des blocs de données, on utilise un bitmap
- D'autres structures sont possibles : listes, arbres, etc.
-\centering
-{ width=100% }
+
+
+--
-[//]: # ----------------------------------------------------------------
## Superblock
-\small
Le superblock stocke des informations globales sur le FS :
- Signature du FS, nombre d'inodes total, nombre de blocs total, taille du bitmap des inodes, etc.
-\centering
-{ width=100% }
+
+
+--
-[//]: # ----------------------------------------------------------------
## Combien d'inodes ?
Le nombre d'inodes détermine le nombre maximum de fichiers pouvant être créés sur un FS
-\vspace{.5cm}
+<fieldset class="warning">
+
+Combien d'inodes faut-il réserver pour un FS d'une taille donnée ?
-**\textcolor{myred}{Combien d'inodes faut-il réserver pour un FS d'une taille donnée ?}**
+</fieldset>
+
+--
-[//]: # ----------------------------------------------------------------
## Combien d'inodes : mkfs.minix
- `mkfs.minix` se base sur la taille du disque (`DS`) ; ci-dessous `fs_blocks` = nombre total de blocs dans le FS
@@ -308,37 +288,14 @@ Le nombre d'inodes détermine le nombre maximum de fichiers pouvant être créé
- Ensuite, arrondi au prochain multiple de la taille d'un inode (32 bytes)
- Exemple :
- soit un disque de 64 MB et des blocs de 1 KB\
- $\rightarrow$ `inodes = (64*1024/3 + 32) & 0xFFFFFFE0 = 21856`
+ `$\rightarrow$ inodes = (64*1024/3 + 32) & 0xFFFFFFE0 = 21856`
+
+--
-[//]: # ----------------------------------------------------------------
## Combien d'inodes : mke2fs (ext2/3/4)
-- `mke2fs` se base sur un paramètre nommée \textcolor{myblue}{\texttt{bytes-per-inode}}
-- Indique de créér un inode pour chaque \textcolor{myblue}{\texttt{bytes-per-inode}} bytes d'espace disque
+- `mke2fs` se base sur un paramètre nommée *bytes-per-inode*
+- Indique de créér un inode pour chaque *bytes-per-inode* bytes d'espace disque
- Exemple :
- - soit un disque de 64 MB et \textcolor{myblue}{\texttt{bytes-per-inode}} = 4096\
- $\rightarrow$ `inodes = 64*1024*1024/4096 = 16384`
-
-[//]: # ----------------------------------------------------------------
-## Ressources
-
-\small
-
-- Operating Systems: Three Easy Pieces, Remzi H. and Andrea C. Arpaci-Dusseau. Arpaci-Dusseau Books\
-\footnotesize [\textcolor{myblue}{http://pages.cs.wisc.edu/~remzi/OSTEP/}](http://pages.cs.wisc.edu/~remzi/OSTEP/)
- - livre disponible à la bibliothèque
-
-\small
-
-- `mkfs.minix` source code\
-\footnotesize [\textcolor{myblue}{https://github.com/util-linux/util-linux/blob/master/disk-utils/mkfs.minix.c}](https://github.com/util-linux/util-linux/blob/master/disk-utils/mkfs.minix.c)
-
-\small
-
-- The Second Extended File System - Internal Layout\
-\footnotesize [\textcolor{myblue}{https://www.nongnu.org/ext2-doc/ext2.html}](https://www.nongnu.org/ext2-doc/ext2.html)
-
-\small
-
-- Ext4 (and Ext2/Ext3) Wiki\
-\footnotesize [\textcolor{myblue}{https://ext4.wiki.kernel.org/index.php/Main\_Page}](https://ext4.wiki.kernel.org/index.php/Main_Page)
+ - soit un disque de 64 MB et *bytes-per-inode* = 4096\
+ `$\rightarrow$ inodes = 64*1024*1024/4096 = 16384`
diff --git a/9.filesystems/Ressources.md b/9.filesystems/Ressources.md
index 4e54a4c..703758c 100644
--- a/9.filesystems/Ressources.md
+++ b/9.filesystems/Ressources.md
@@ -1,5 +1,11 @@
# Ressources
- [Operating Systems: Three Easy Pieces](http://pages.cs.wisc.edu/~remzi/OSTEP/), Remzi H. and Andrea C. Arpaci-Dusseau. Arpaci-Dusseau Books
+livre disponible à la bibliothèque
-livre disponible à la bibliothèque
\ No newline at end of file
+- `mkfs.minix` [source code](https://github.com/util-linux/util-linux/blob/master/disk-utils/mkfs.minix.c)
+
+- [The Second Extended File System - Internal Layout](https://www.nongnu.org/ext2-doc/ext2.html)
+
+
+- [Ext4 (and Ext2/Ext3) Wiki](https://ext4.wiki.kernel.org/index.php/Main_Page)
\ No newline at end of file
diff --git a/9.filesystems/index.html b/9.filesystems/index.html
index 16d165c..9dfe244 100644
--- a/9.filesystems/index.html
+++ b/9.filesystems/index.html
@@ -42,7 +42,7 @@
<section>
<h1>Systèmes de fichiers</h1>
<p>Guillaume Chanel</p>
- <p>Remerciements à Florent Glück</p>
+ <p>Remerciements à Florent Glück et Mickaël Hoerdt</p>
</section>
</section>
<section data-markdown="01_Systemes_fichiers_intro.md" data-separator-vertical="^\r?\n--\r?\n$"></section>
--
GitLab