statzitz/Latex_template
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

review all typos

Browse source
This commit is contained in:
statzitz 2024-12-15 20:10:02 +01:00
parent 211b3827ec
commit 19a8aae423
7 changed files with 173 additions and 152 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

BIN
02_rapport_sur_les_filesystemes/main.pdf
View file

Binary file not shown.

13
02_rapport_sur_les_filesystemes/parts/conclusion.tex
View file

@ -9,13 +9,14 @@
\addcontentsline{toc}{chapter}{Conclusion}
Ce projet, rtfs, ainsi que de faire ce rapport et se renseigner sur le fonctionnement de ext2, nous aurra été incroyablement utile.
Non seulement il nous aurra permis de nous faire de véritables connaissances sur la création des systèmes de fichiers, ainsi de comment ils sont pensés, mais surtout, il nous aurra permis, pour la première fois de nos vie, de nous pencher en détails sur le fonctionnement des modules noyeau de linux.
Jusqu'as présent, nous pensions que c'était une chose impossible de rentrer dedans même si on avais déjà la théorie.
Grace à ce projet, nous comprenons désormais comment un module noyeau se lie à ceuli-ci.
Faire ce rapport et se renseigner sur le fonctionnement de ext2, nous aura été incroyablement utile.
Non seulement il nous aura permis de nous faire de véritables connaissances sur la création des systèmes de fichiers, mais aussi de comprendre comment ils sont pensés.
Mais aussi, pour la première fois de nos vies, il nous aura permis de nous pencher en détails sur le fonctionnement des modules noyau de linux.
Jusqu'à présent, nous pensions que c'était une chose impossible de rentrer dedans même si on avait déjà la théorie.
Grace à ce projet, nous comprenons désormais comment un module noyau se lie à celui-ci.
Il nous aurra aussi, ce projet, permi de rentrer dans le fonctionnement de vfs pour ainsi comprendre le mécanisme de pages.
vfs récupère les informations par pages que le système de fichier lui passe, en les lisant depuis les secteurs physique du disque.
Le projet rtfs nous aura aussi permis de rentrer dans le fonctionnement de vfs pour ainsi comprendre le mécanisme de pages.
vfs récupère les informations par pages que le système de fichier lui passe, en les lisant depuis les secteurs physiques du disque.
\vspace{10pt}

13
02_rapport_sur_les_filesystemes/parts/introduction.tex
View file

@ -8,13 +8,16 @@
\chapter*{Introduction}
Dans linux, tout est fichiers.
Dans linux, tout est fichier.
Cette phrase n'est pas à prendre à la légère, dans linux, vraiment, tout est fichier.
La raison, c'est qu'ils ont réalisé un système de fichier virtuel, le vfs, tellement incroyable, qui simplifie considérablement le mécanisme pour faire un système de fichier, tout en lui fournissant une interface extrèmement facile d'utilisation.
La raison est qu'ils ont réalisé un système de fichier virtuel : le vfs.
Il est tellement incroyable qu'il simplifie considérablement le mécanisme pour faire un système de fichier, tout en lui fournissant une interface extrêmement facile d'utilisation.
Grace à ca, même un processus ou une souris sont des fichiers.
Leur systèmes de fichiers respectifs, proc et devtmpfs, font le lien avec la location mémoire ou il y à leur addresses.
Le but de ce document est de se plonger dans le mécanisme des systèmes de fichiers ainsi que de vfs, en commancant par annalyser l'existant, ext2, puis en s'y inspirrant un peu, réaliser notre propre système de fichier, un module noyeau qui sera intégré à vfs.
Grace à ça, même un processus ou une souris sont des fichiers.
Leurs systèmes de fichiers respectifs, proc et devtmpfs, font le lien avec l'allocation mémoire où il y a leur adresse.
Le but de ce document est de se plonger dans le mécanisme des systèmes de fichier ainsi que de vfs.
Nous allons commencer par annalyser l'existant, c'est à dire ext2, puis en s'y inspirant un peu, nous allons réaliser notre propre système de fichier.
Ce sera un module noyau qui sera intégré à vfs, permettant ainsi de récupérer son interface utilisateur.
Nous avons mis en annexe à ce document tout le code que nous avons produit.

122
02_rapport_sur_les_filesystemes/parts/part1.tex
View file

@ -5,53 +5,60 @@
\begin{document}
\chapter{Le fonctionnement de notre systeme de fichier de reference : ext2}
\chapter{Le fonctionnement de notre système de fichiers de référence : ext2}
Réalisé entre 1992 et 1995, ext2 est le système de fichier que les distributions linux ont utilisé pendant des années, et qui est toujours packagé avec les distributions à ce jour.
Bien que par la suite à été amélioré avec ext3 et ext4, il reste néenmoins le premier système de fichiers de linux qui était suffisament fonctionnel pour pour être réellement utilisé.
Cette partie sera une simple analyse de haut niveau du fonctionnement de ext2, étant donné que pour réaliser une chose, il est nécessaire d'au moins regarder l'éxistant.
Bien que par la suite il ait été amélioré avec ext3 et ext4, il reste néanmoins le premier système de fichiers de linux qui était suffisament fonctionnel pour être réellement utilisé.
Cette partie sera une simple analyse de haut niveau du fonctionnement de ext2, étant donné que pour réaliser une chose, il est nécessaire d'au moins au préalable, regarder l'existant.
On utilisera l’abréviation fs (“filesystem”) pour désigner le système de fichier.
\vspace{10pt}
\section{La notion de groupe de block}
\section{La notion de groupe de blocks}
Ext2 à été conçu d'après la notion de block.
En effet, la plupart des systèmes de fichiers tournent autour de la notion de blocks de données.
Les données sont stockés sur des secteurs et des groupes de secteurs entiers logique.
Ce sont les pilotes de disques qui s'occupent de gérer le materiel, ext2 prends juste un groupe de secteurs logique que nous nomerons partition logique que le système lui passe, et écrit dessus.
Ext2 découpe la partition logique qui lui est passé en groupe de blocks.
Chaque groupe de block commence par une copie de son block super, un déscripteur du groupe comprenant un block permettant de garder trace des blocks réservés aux données, un autre block pour garder la trace des blocks réservés aux inodes et une table des inodes.
Enfin, un groupe de block comprendra aussi un espace pour stocker les données.
La copie du super block en début de chaque groupe de block permet que si il y à un probleme, les informations les plus importantes sur le système de fichier puissent être récupérées.
Ce système de fichier réserve les secteurs du disque à une seule utilitée chaqu'un, et donc, le block super est un groupe de secteur, un inode est aussi un groupe de secteurs, un fichiers en est un autre, c'est la raison pour laquelle il est nécessaire de garder trace des secteurs déjà aloués.
Le descripteur du groupe garde donc en mémoire ou commence quoi, il comprends aussi les blocks permettant de garder trace des secteurs disponible à la fois pour les données et les inodes, ainsi que la table des inodes.
En effet, la plupart des systèmes de fichiers tournent autour de cette notion de block de données.
Les données sont stockées sur des secteurs et des groupes de secteurs entiers logiques.
Ce sont les pilotes de disques qui s'occupent de gérer le materiel.
Le système donne à Ext2 un groupe de secteurs logiques que nous nomerons partition logique et écrit dessus.
Ext2 découpe la partition logique qui lui est passée en groupe de blocks.
Chaque groupe de blocks commence par une copie de son block super.
Ce groupe de block contient ensuite un descripteur de groupe comprenant un block qui permet de garder la connaissance des blocks réservés aux données.
Il contient aussi un autre block pour garder la trace des blocks réservés aux inodes et enfin une table des inodes.
Un groupe de block contiendra pour finir un espace pour stocker les données.
La copie du super block en début de chaque groupe de block permet de récupérer les informations essentielles du système de fichier en cas de problème.
Ce système de fichiers réserve les secteurs du disque à une seule utilité.
Par exemple : le block super est un groupe de secteur. Un inode est aussi un groupe de secteurs. Un fichiers en est un autre.
C'est la raison pour laquelle il est nécessaire de garder trace des secteurs déjà aloués; le role du descriteur du groupe est donc de décrire les secteurs disponibles dans son groupe.
\includegraphics[width=450pt]{ext2_block_group.png}
Maintenant que l'on as fait l'introduction sur comment sont organisés à haut niveau ext2, ainsi de comment ext2 garde trace des secteurs disponibles et déjà alloués, passons à décrire plus en détails ce qu'est un inode et comment ca marche.
Maintenant que l'on a fait l'introduction sur l'organisation à haut niveau de ext2 et de l'importance de garder trace des secteurs disponibles et déjà alloués, passons à décrire plus en détails ce qu'est un inode et comment ça marche.
\vspace{10pt}
\section{La notion d'inode}
D'un point de vue de vfs, un inode est simplement un lien vers une entitée du système de fichier.
Cela peut-être vers un dosser, vers un fichier, un lien symbolique, et je peux siter encore plein d'autres fichier spéciaux.
On peut retrouver le mot node dans inode, on peut donc dire qu'il simbolyse un noeud logique du fs.
D'un point de vue de vfs, un inode est simplement un lien vers une entité du système de fichier.
Cela peut-être vers un dossier, un fichier, un lien symbolique, et je peux siter encore pleins d'autres fichiers spéciaux.
On peut retrouver le mot node dans inode, on peut donc dire qu'il symbolise un noeud logique du fs.
Puisque les inodes correspondent à l'architecture, l'arboressence du système de fichier, il garde dans chaque groupe de block une table des inodes contenant tout les inodes se trouvant dans le groupe.
Etant donné qu'un inode peut-être autemps un dossier que un fichier, les dossiers et les fichiers aurront la même structure dans le système de fichier.
Puisque les inodes correspondent à l'architecture et à l'arborescence du système de fichier, ext2 garde dans chaque groupe de block une table des inodes contenant tous les inodes se trouvant dans le groupe.
Etant donné qu'un inode peut-être autant un dossier qu'un fichier, les dossiers et les fichiers auront la même structure dans le système de fichier.
On peut même dire que les dossiers sont des fichiers spéciaux.
Un inode contient un Mode, disant si c'est un dossier ou un fichier, ainsi que les permissions unix de l'inode.
Il contient aussi des informations sur son propriétaire, comme son UID et son GID.
Un inode contient un mode disant si c'est un dossier ou un fichier, ainsi que les permissions UNIX de l'inode, mais aussi des informations sur son propriétaire, comme son UID et son GID.
Évidemment, il contient une taille, correspondant à sa taille sur les différents blocks de données qu'il possède.
Aussi des informations correspondant à quand l'inode à été créer, quand il à été modifié, et quand il à été accédé pour la dernière fois.
Enfin, il contient des liens vers des blocks de données, plus précisément 20 liens dirrects, et 3 autres.
Il est doté aussi d'informations correspondant à quand l'inode a été créé, quand il a été modifié, et quand il a été ouvert pour la dernière fois.
Enfin, il contient des liens vers des blocks de données, plus précisément 20 liens directs, et 3 autres.
Ces 3 derniers pointent sur toujours plus de blocks de pointeurs.
Le premier pointe sur un secteur reservé à des pointeurs de blocks de données, le deuxième sur un secteur contenant des pointeurs sur des blocks de pointeurs qui eux à leur tours pointeront sur des données, enfin, le troisième pointe sur un secteur contenant lui aussi que des pointeurs, mais ce coup-ci avec encore un niveau d'indirection en plus.
Le premier des trois pointe sur un secteur reservé à des pointeurs de blocks de données.
Le deuxième sur un secteur contenant des pointeurs sur des blocks de pointeurs qui eux à leur tours pointeront sur des données.
Enfin, le troisième pointe sur un secteur contenant lui aussi que des pointeurs, mais ce coup-ci avec encore un niveau d'indirection en plus.
C'est à l'intérieur de ces blocks de données que se trouve le fichier.
\begin{center}
@ -60,37 +67,39 @@
\end{center}
Il est intéressant de noter qu'un inode n'as pas de nom.
Il est intéressant de noter qu'un inode n'a pas de nom.
C'est celui qui le référence qui lui donne son nom.
La racine, c'est à dire le première inode du système de fichier n'as pas de nom non plus, c'est la location ou il est monté qui lui donne son nom.
Par conséquent, chaque dossiers, y compris le dossier racine, sera donc chargé de conserver les noms de ce qu'il contient et c'est lors de leur chargement, en lisant les données sur lesquelle l'inode pointe que l'on pourra déterminer leur contenu.
La racine, c'est à dire le premier inode du système de fichier, n'a pas de nom non plus.
C'est la location où il est monté qui lui donne son nom.
Par conséquent, chaque dossier, y compris le dossier racine, sera donc chargé de conserver les noms de ce qu'il contient et c'est lors de leur chargement, en lisant les données sur lesquelles l'inode pointe que l'on pourra déterminer leur contenu.
Voyons maintenant comment les données sont structurées au sein des blocks de données pour former les fichiers.
\vspace{10pt}
\section{Les structures de fichier}
\section{La structure des fichiers}
\subsection{Un fichier normal}
\subsection{Les fichiers normaux}
Pour stocker les données des fichiers, ext2 est extrèmement simple.
Simplement il met des données dans les blocks de données, en commencant par le premier et un à un, au fur et à mesure ou il lui est rajouté des données, il alloue d'autres blocks de données.
Dans le cas de la suppression de données, il lui suffit aussi de retirer les pointeurs sur les blocks de données, ainsi que les marquer comme libres dans le descripteur de groupe.
Pour stocker les données des fichiers, ext2 est extrêmement simple.
Il met des données dans les blocks de données, en commençant par le premier et un à un, au fur et à mesure qu'il lui est rajouté des données, il alloue d'autres blocks de données.
Dans le cas de la suppression de données, il lui suffit de retirer les pointeurs des blocks de données, ainsi que de les marquer comme libre dans le descripteur de groupe.
On notera fichier de données un fichier normal, contenant des données que l'on peut écrire dedans comme on le souhaies pour les différencier de fichier spéciaux comme les dossiers.
Le terme fichier désormais correspondera autemps aux fichier de données que aux fichiers spéciaux.
On notera fichier de données un fichier normal, contenant des données que l'on peut écrire dedans comme on le souhaite pour les différencier de fichiers spéciaux comme les dossiers.
Le terme fichier pourra désormais correspondre autant aux fichier de données qu'aux fichiers spéciaux.
\vspace{10pt}
\subsection{Un fichiers spéciaux - le cas des dossiers}
\subsection{Les fichiers spéciaux - le cas des dossiers}
Les dossiers sont des fichiers très spéciaux, puisque plutôt que de stocker de simples données, ils contiennent les chemins d'autres fichiers et d'autres dossiers.
Ici quand on parle de chemin, on parle simplement d'un lien vers un inode.
Toujours dans ext2, il à été fait le choix que les deux premiers liens contenus dans un fichier sont des liens pointant sur l'inode du dossier, ainsi que l'inode du parent du dossier.
Toujours dans ext2, il à été fait le choix que les deux premiers liens contenus dans un fichier soient des liens pointant sur l'inode du dossier, ainsi que l'inode du parent du dossier.
Les données contenu dans un dossier sont tout simplement une liste de pointeurs de fichier.
Elles contiennent toutes un lien vers un inode dans la table des inodes, la taille que cette entité prends dans le dossier, la taille de son nom, ainsi que, enfin, son nom.
Les données contenues dans un dossier sont tout simplement une liste de pointeurs de fichiers.
Elles contiennent toutes : un lien vers un inode dans la table des inodes, la taille que cette entité prends dans le dossier, la taille de son nom, et enfin son nom.
La représentation suivante permet de donner un bon apperçu du contenu d'un dossier pour ext2.
La représentation suivante permet de donner un bon aperçu du contenu d'un dossier pour ext2.
\begin{center}
@ -98,29 +107,32 @@
\end{center}
Evidemment, un dossier, dans un cas réel contiendras probablement beaucoup plus d'entrées que dans cet example.
Evidemment, un dossier, dans un cas réel contiendra probablement beaucoup plus d'entrées que dans cet exemple.
\vspace{10pt}
\section{Intégration au VFS - les opérations}
\section{Intégration au vfs - les opérations}
Le VFS est un mécanisme formidable de linux.
C'est lui qui est le résponsable du fait que tout est fichier.
La raison probable de cet raison, est son interface d'opérations sur pointeurs de fonctions.
Le vfs est un mécanisme formidable de linux.
C'est lui qui est le responsable du fait que tout est fichier.
La raison probable est son interface d'opérations basé sur des pointeurs de fonctions.
En effet, vfs à des opérations qui sont réservés au block super, des opérations réservés aux inodes, des opérations réservés aux fichiers, ainsi que des opérations réservés aux opérations sur le fichier.
Elle sont toutes optionnels, cependant, le fait de ne pas les implémenter rend leur utilisation impossible, c'est à dire que par example, au niveau inode, si on n'implementes pas l'opération mkdir sur les inodes, il sera impossible de créer des dossiers.
Si on implémentes pas l'opération create, il sera aussi impossible de créer de nouveaux fichiers de données.
Au niveau fichier, si on implements pas l'opération read, il sera aussi impossible de lire un fichier.
Ext2 implemente donc évidement une bonne quantitée de ces opération, de tel sorte à ce qu'il soit possible autemps de créer des fichiers, autemps que de les renomber que de les supprimer.
Il permet aussi de créer des fichiers spéciaux autres que les dossiers, comme les fichiers fifo ou les liens symboliques et j'en passe.
En théorie, il serait même possible de réaliser un système de fichier, dont les inodes feraient à la fois dossier et fichiers.
Elles sont toutes optionnelles.
Cependant, le fait de ne pas les implémenter rend leur utilisation impossible, c'est à dire par exemple, au niveau inode, si on n'implémente pas l'opération mkdir sur les inodes, il sera impossible de créer des dossiers.
Si on n'implémente pas l'opération create, il sera impossible de créer de nouveaux fichiers de données.
Au niveau fichier, si on n'implémente pas l'opération read, il sera impossible de lire un fichier.
Au point actuel, nous pouvons donc commencer à deviner comment l'on vas pouvoir réaliser notre système de fichier.
Dans un premier temps, nous allons faire de la théorie et du dessein, c'est à dire, déterminer ce qu'est un fichier, comment il sera contenu dans la mémoire, et aussi, comment il sera référencé par les inodes.
Il nous sera évidement obligés de réfléchir à ce qu'est un dossier pour notre système de fichier, ainsi que de penser aux opérations à implémenter.
Notre souhait étant simplement de réaliser un système de fichier basique, nous réaliserons uniquement les opération de bases, tel que la création et la lecture des dossiers, ainsi que la création, la lecture et l'écriture des fichiers.
Les opérations plus compliqués tels que celles sur le super block ne seront donc pas implémentés.
Ext2 implémente donc évidemment une bonne quantité de ces opérations de telle sorte qu'il soit possible autant de créer des fichiers, que de les renommer ou de les supprimer.
Il permet aussi de créer des fichiers spéciaux autre que les dossiers, comme les fichiers fifo ou les liens symboliques et j'en passe.
En théorie, il serait même possible de réaliser un système de fichier dont les inodes feraient à la fois dossiers et fichiers.
Au point actuel, nous pouvons donc commencer à deviner comment nous allons pouvoir réaliser notre système de fichier.
Dans un premier temps, nous allons faire de la théorie et du dessin, c'est à dire, déterminer ce qu'est un fichier, comment il sera contenu dans la mémoire, et aussi, comment il sera référencé par les inodes.
Il nous sera évidemment obligé de réfléchir à ce qu'est un dossier pour notre système de fichier, ainsi que de penser aux opérations à implémenter.
Notre souhait étant simplement de réaliser un système de fichier basique.
Nous nous contenterons uniquement des opération de bases, telles que la création et la lecture des dossiers, ainsi que la création, la lecture et l'écriture des fichiers.
Les opérations plus compliquées tels que celles sur le super block ne seront donc pas implémentées.
\vspace{10pt}

100
02_rapport_sur_les_filesystemes/parts/part2.tex
View file

@ -5,37 +5,37 @@
\begin{document}
\chapter{Design notre propre système de fichier}
\chapter{Design de notre propre système de fichiers}
La première chose à quoi on à du penser concernant notre système de fichier fut son nom.
Nous avons choisis RTFS, parce que cela ressemblais à RTFM et cela nous à fait rire.
Au fil du projet, quand on à commencé sa réalisation, étant donné qu'il contenait des nombres magiques à tout les niveaux, nous avons commencés à lui donner le surnom de 'Magic system'.
La raison pour laquelle on l'as réalisés à été uniquement pour apprendre comment un système de fichier fonctionne, ainsi que comment il se lie à vfs.
Il n'est ainsi pas capable de rivaliser les systèmes de fichiers tels que ext2, et pensé pour être fonctionnel à proprement parlé autemps d'un point de vue des limites de ses performance, que des limites des opérations qui lui sont implémentés.
La première chose auquelle nous avons dû penser concernant notre système de fichier a été son nom.
Nous avons choisi rtfs, parce que cela ressemblait à RTFM et cela nous a fait rire.
Au fil du projet, quand nous avons commencé sa réalisation, étant donné qu'il contenait des nombres magiques à tout les niveaux, nous avons commencé à lui donner le surnom de 'Magic system'.
La raison pour laquelle nous l'avons réalisé a été uniquement pour apprendre comment un système de fichiers fonctionne, ainsi que comment il se lie à vfs.
rtfs n'est ainsi pas capable de rivaliser avec les systèmes de fichiers tels que ext2, et penser pour être fonctionnel à proprement parlé autant d'un point de vue des limites de ses performances, que des limites des opérations qui lui sont implémentées.
\vspace{10pt}
\section{En-tête de rtfs}
Pour pouvoir déterminer que notre système de fichier est sur un disque, il faut qu'il y laisse une marque de distinction.
C'est ce que l'on appelles le nombre magique.
Pour pouvoir déterminer que notre système de fichier est sur un disque, il doit laisser une trace.
C'est ce que l'on appelle le nombre magique.
La première donnée se trouvant sur rtfs est ainsi un nombre magique, plus précisément 0x01002FF0.
Nous avons aussi choisi, à tord, parce que l'on ne connaissait rien aux systèmes de fichiers à ce moment la, aussi d'y stocker la taille d'un secteur.
Cela était une erreur, premièrement parce que vfs, quand il appelle un système de fichier, il lui passe déjà la taille d'un secteur, ensuite, parce que nous ignorions que nous utiliserions l'objet buffer head pour réaliser les lectures et écritures.
Nous avons choisi, à tord, parce que nous ne connaissions rien aux systèmes de fichiers à ce moment là, aussi d'y stocker la taille d'un secteur.
Cela était une erreur, premièrement parce que vfs, quand il appelle un système de fichier, il lui passe déjà la taille d'un secteur, ensuite, parce que nous ignorerions que nous utiliserions l'objet buffer head pour réaliser les lectures et écritures.
En effet, vfs se charge aussi de communiquer avec le matériel.
Nous nous retrouvons ainsi avec un block super minimal, avec juste deux données stockés dedans.
Nous nous retrouvons ainsi avec un block super minimal, avec juste deux données stockées dedans.
Rtfs à un block super unique, stocké au début du disque.
Comparé à ext2, qui possède au début de chaque groupe toute une quirielle d'informations, rtfs se veut vraiment minimal.
L'objectif recherché était de nous permettre de comprendre le coeur d'un système de fichier et il est plutôt réussi.
Nous avons aussi fait le choix délibéré de séparer chaque entité par les secteurs matériels, plutôt que d'essayer d'optimiser le stockage pris par notre système de fichier.
Nous avons aussi fait le choix délibéré de séparer chaque entité par les secteurs matériels, plutôt que d'essayer d'optimiser le stockage prit par notre système de fichier.
Le super block réserve ainsi le secteur numéro 0.
Le fait d'avoir un block super, c'est bien, mais cela n'est pas suffisant pour pouvoir monter un système de fichier.
C'est pour cela que l'entête de notre système de fichier est composé de 2 secteurs.
Le block super, situé sur le secteur numéro 0, ainsi que l'inode racine, situé sur l'inode numéroté 1.
L'inode racine n'as rien de différent des autres inodes, si on omet le fait qu'il est nécessaire au fonctionnement de notre système de fichier, et ainsi, par conséquent fait partie de son entête.
L'inode racine n'a rien de différent des autres inodes, si on omet le fait qu'il est nécessaire au fonctionnement de notre système de fichier, et ainsi, par conséquent fait partie de son entête.
Nous allons voir dans la prochaine partie ce qu'est un inode pour notre système de fichier.
Voici donc à quoi ressemble l'entête de notre système de fichier.
@ -51,9 +51,10 @@
\subsection{L'entête d'un inode}
Un inode est un noeud du système de fichier.
Pour rtfs, il est composé tout dabord d'une entête, ce qui lui permet d'être reconnu et lus par rtfs, puis d'un corps dans le même secteur, ce qui lui permet de pointer sur ses enfants.
Pour rtfs, il est composé tout dabord d'une entête, ce qui lui permet d'être reconnu et lu par rtfs, puis d'un corps dans le même secteur, ce qui lui permet de pointer sur ses enfants.
A ce moment la du design, nous n'avions pas la moindre idée de l'erreur que nous faisions en faisant ca, cependant, nous avions fait le choix que ce qui déterminait qu'un secteur était occupé, était le fait qu'il commençait par un nombre magique.
A ce moment la du design, nous n'avions pas la moindre idée de l'erreur que nous faisions en faisant ça.
Cependant, nous avions fait le choix que ce qui déterminait qu'un secteur était occupé, était le fait qu'il commençait par un nombre magique.
Ainsi, dans l'entête d'un inode de rtfs, nous retrouvons un nombre magique spécifique aux inodes, 0x01002FF1.
Nous y retrouvons aussi un mode unix, un UID, un GID et une taille.
Ce qui différencie dans l'entête d'un inode un dossier d'un fichier est le DIR (directory) bit ainsi que le REG (regular) bit du mode.
@ -65,8 +66,8 @@
\end{center}
L'entête de l'inode, mis à part le mode, est le même autemps pour un dossier que pour un fichier.
Cependant, pour le corps d'un inode, c'est complêtement différent.
L'entête de l'inode, mis à part le mode, est le même autant pour un dossier que pour un fichier.
Cependant, pour le corps d'un inode, c'est complètement différent.
\vspace{10pt}
@ -76,14 +77,15 @@
Commençons par décrire le corps d'un inode de dossier.
Il est très simple.
Il s'agit d'une chaine de pointeurs d'entités.
Il y en à jusqu'as ce que le secteur soit terminé.
Il y en a jusqu'à ce que le secteur soit terminé.
Le nombre de pointeurs d'entité pouvant se trouver dans un dossier est ainsi déterminé par la taille d'un secteur.
Chaque pointeurs d'entités possèdent un nombre magique.
Ce choix aussi était un pauvre choix de notre part qui nous aurra coûté de la place précieuse, surtout que l'on aurrait pu faire sans.
Ce nombre magique vaut 0x01002FF2, le même pour tout les pointeurs d'entités se trouvant dans les dossiers.
Les pointeurs d'entités sont aussis composés du nom de l'entitée sur lesquelles elle poitent, qui est stocké sur 64 caractères ASCII, c'est à dire 512 bits.
Enfin, un pointeur d'entité est composé d'un pointeur, c'est à dire le numéro de secteur sur lequel se situe l'inode ciblé. qui est stocké sur 32 bits.
Chaque pointeur d'entité possède un nombre magique.
Ce choix aussi était un pauvre choix de notre part qui nous aura coûté de la place précieuse, surtout que nous aurions pu faire sans.
Ce nombre magique vaut 0x01002FF2, le même pour tous les pointeurs d'entités se trouvant dans les dossiers.
Les pointeurs d'entité sont aussi composés du nom de l'entité sur lequelle elle pointe, qui est stocké sur 64 caractères ASCII, c'est à dire 512 bits.
Enfin, un pointeur d'entité est composé d'un pointeur, c'est à dire le numéro de secteur sur lequel se situe l'inode ciblé.
Il est stocké sur 32 bits.
Voici la structure d'un pointeur d'entité dans un inode dossier.
@ -94,50 +96,50 @@
\end{center}
Imaginons que notre disque possède des secteurs physique de taille minimals, c'est à dire 512 octets, que l'entête fait déjà 16 octets (128 bits), et que chaque pointeurs d'entités fait 72 octets (576 bits) Si on fait un simple calcul :
Imaginons que notre disque possède des secteurs physique de taille minimal, c'est à dire 512 octets, que l'entête fait déjà 16 octets (128 bits), et que chaque pointeur d'entité fait 72 octets (576 bits) Si on fait un simple calcul :
$$
(512 - 16) // 72 = 6
$$
Chaque inode de dossiers ne pourra donc contenir uniquement 6 liens dans le cas ou la taille d'un secteur est minimal, c'est à dire 512 octets.
Chaque inode de dossiers ne pourra donc contenir que 6 liens dans le cas où la taille d'un secteur est minimal, c'est à dire 512 octets.
\vspace{10pt}
\subsection{Le corps d'un inode - un fichier}
Nous avons pensé de la même manière les inodes fichiers.
Leur seule différence avec l'inode dossier, c'est que les pointeurs d'entités sont maintenant des pointeurs de données, et, le dernier, était censé être un lien vers un secteur réservés aux pointeurs de données.
Chaque secteurs réservés aux pointeurs de données étaient censés avoir à leur fin un pointeur vers un autre secteur réservé aux pointeurs de données, lui permettant de s'agrandir.
Nos inodes fichiers ont été pensés de la même manière que les dossiers.
Leur seule différence avec les inodes dossiers, est que les pointeurs d'entités sont maintenant des pointeurs de données, et, le dernier pointeur de donnée du secteur, était censé être un lien vers un secteur réservé aux pointeurs de données.
Chaque secteur réservé aux pointeurs de données était censé avoir à sa fin un pointeur vers un autre secteur réservé aux pointeurs de données, lui permettant de s'agrandir.
Les pointeurs de données sont les mêmes que les pointeurs d'entités, à part que leur nombre magique est différent.
On peut aussi noter qu'ils ne contiennent pas de nom, ce qui permet d'en mettre beaucoup plus dans un inode.
Par manque de temps, et surtout parce que l'on à du adapter notre système de fichier au dernier moment nous n'avons pas pu implémenter les pointeurs de pointeurs de données.
Nous allons y revenir la dessus.
Par manque de temps, et surtout parce que nous avons dû adapter notre système de fichier au dernier moment nous n'avons pas pu implémenter les pointeurs de pointeurs de données.
Nous allons revenir la dessus.
\vspace{10pt}
\section{L'algorithme pour déterminer un secteur libre}
Pour rtfs, un secteur libre est un secteur ne commençant pas par un nombre magique.
Par consécant, c'est un algorithme plutôt facile à réaliser.
Pour chaque secteurs en commançant par le premier, on regarde si il à un nombre magique.
Si oui, tester le secteur suivant et continuer jusqu'a en trouver un de libre.
Par conséquant, c'est un algorithme plutôt facile à réaliser.
Pour chaque secteur en commançant par le premier, on regarde s'il a un nombre magique.
Si oui, tester le secteur suivant et continuer jusqu'à en trouver un de libre.
Dans le cas ou aucun n'as été trouvé comme libre, retourner ENOMEM, le code d'erreur associé au fait qu'il n'y à plus de secteurs disponible dans le système de fichier.
Dans le cas où aucun n'a été trouvé comme libre, retourner ENOMEM, le code d'erreur associé au fait qu'il n'y a plus de secteur disponible dans le système de fichier.
\vspace{10pt}
\section{La théorie derière nos fichiers}
\section{La théorie derrière nos fichiers}
Cette partie est uniquement théorique, étant donné que dans la pratique, c'était au moment de la réaliser que l'on est tombé sur un os.
Un gros problème, qui nous as fait repenser au dernier moment comment notre système de fichier devait stocker les fichiers.
Cette partie est uniquement théorique, étant donné que dans la pratique, c'était au moment de la réaliser que sommes tombé sur un os.
Un gros problème, qui nous a fait repenser au dernier moment comment notre système de fichier devait stocker les fichiers.
Rappelons que notre système de fichier était censé considérer qu'un secteur était libre à partir du moment qu'il ne possédait pas, en son début un nombre magique.
Ainsi, dans notre système de fichier théorique, une donnée se devait être sur un secteur commancant par un nombre magique.
Il aurrait du se trouver au début de chaque secteur de données un nombre magique, puis enfin, les données après.
Rappelons que notre système de fichier était censé considérer qu'un secteur était libre à partir du moment où il ne possédait pas, en son début un nombre magique.
Ainsi, dans notre système de fichier théorique, une donnée se devait d'être sur un secteur commançant par un nombre magique.
Il aurait dû se trouver au début de chaque secteur de données un nombre magique, puis enfin, les données après.
\begin{center}
@ -145,17 +147,17 @@
\end{center}
De cette manière, quand notre système de fichier souhaite trouver un secteur libre, il à juste à regarder si il y à un nombre magique en son début.
Cette méthode aurrait du marcher, si le vfs, plus précisément ses opérations de lectures et d'écriture ne partait pas du principe qu'un secteur de donnée devait contenir que de la donnée.
En effet, peu importe les efforts que l'on à fait pour que ca marche, à chaque fois que l'on à écrit dans le disque le nombre magique correspondant aux données, c'est à dire 0x01002FF4, les données l'écrasait.
Cela rendait le block de donnée illisible, et par conséquent, le vidait.
Non seulement cela, mais à cause de ca, rtfs le considérait libre, et si l'on souhaitait créer un nouvel inode, puisque rtfs trouve cet endroit sur le disque comme libre, il à donc la bétise de le séléctionner.
De ce fait, par la suite le fait de réecrire dans le fichier vas écraser l'inode nouvellement créer, mais pas défaire le lien avec son inode parent.
De cette manière, quand notre système de fichier souhaite trouver un secteur libre, il a juste à regarder s'il y a un nombre magique en son début.
Cette méthode aurait du marcher, si le vfs, plus précisément ses opérations de lecture et d'écriture ne partaient pas du principe qu'un secteur de donnée devait contenir que de la donnée.
En effet, peu importe les efforts que l'on à fait pour que ça marche, à chaque fois que l'on a écrit dans le disque le nombre magique correspondant aux données, c'est à dire 0x01002FF4, les données l'écrasaient.
Cela rendait le block de données illisible, et par conséquent, le vidait.
Non seulement cela, mais à cause que rtfs le considérait libre, si on souhaitait créer un nouvel inode, rtfs le séléctionnait par erreur.
De ce fait, par la suite le fait de réecrire dans le fichier vas écraser l'inode nouvellement créé, mais pas défaire le lien avec son inode parent.
La solution que l'on a trouvé à donc été d'adapter notre système de fichier à ce fonctionnement de vfs, et c'est aussi le sujet de la prochaine partie.
Evidemment, étant donné qu'elle à été pensé au dernier moment avec la plupart du code déjà fait, cette solution est vraiment loin d'être parfaite, cependant c'est la seule que l'on ai pu faire avec le peu de temps qu'il nous restait.
La solution que l'on a trouvé a donc été d'adapter notre système de fichier à ce fonctionnement de vfs, et c'est aussi le sujet de la prochaine partie.
Evidemment, étant donné qu'elle à été pensée au dernier moment avec la plupart du code déjà fait, cette solution est vraiment loin d'être parfaite, cependant c'est la seule que l'on ait pu faire avec le peu de temps qu'il nous restait.
Aussi, à cause de ce gros problème, nous n'avons pas réussi à prendre le temps de permettre à nos fichier d'être stockés en plusieurs secteurs, et par consécant, la taille maximal de nos fichiers est d'un secteur.
Aussi, à cause de ce gros problème, nous n'avons pas réussi à prendre le temps de permettre à nos fichiers d'être stockés en plusieurs secteurs, et par conséquent, la taille maximale de nos fichiers est d'un secteur.
\vspace{10pt}

75
02_rapport_sur_les_filesystemes/parts/part3.tex
View file

@ -8,30 +8,32 @@
\chapter{Rtfs, la pratique}
\section{Les changements que l'on à du réaliser par rapport à la théorie}
\section{Les changements que l'on a dû réaliser par rapport à la théorie}
Comme Nous l'avons précisé dans le chapitre précédent, nous n'avons pas réussi à appliquer ce que nous avions choisi de faire à la lettre, et à la fin alors que la plupart des mécanismes de notre système de fichier étaient déjà fait, on est tombé sur un problème.
Comme Nous l'avons précisé dans le chapitre précédent, nous n'avons pas réussi à appliquer ce que nous avions choisi de faire à la lettre, et à la fin alors que la plupart des mécanismes de notre système de fichier étaient déjà fait, nous sommes tombé sur un problème.
Impossible d'écrire les données après un nombre magique sur un secteur à cause du fonctionnement de vfs.
à ce moment la, nous avons choisi de changer notre fs, même si cela voullait dire que le résultat ne serait pas parfait.
Nous avons commencé par retirer de notre fs le nombre magique en début de secteur de donnée, puis, nous avons décidé que tout les secteurs pairs seraient réservés aux données à l'exception du secteur 0, et tout les secteurs impairs seraient réservés aux inodes.
À ce moment la, nous avons choisi de changer notre fs, même si cela voulait dire que le résultat ne serait pas parfait.
Nous avons commencé par retirer de notre fs le nombre magique en début de secteur de donnée, puis, nous avons décidé que tous les secteurs pairs seraient réservés aux données à l'exception du secteur 0, et tous les secteurs impairs seraient réservés aux inodes.
Ce choix à d'énormes problèmes, étant donné que la moitié du disque est réservé pour les inodes, la moitié du disque est perdu.
Cela à aussi un autre problème.
Etant donné que nous avons du faire le changement au dernier moment, et que avant on avait décidé que les secteurs de données aurraient un nombre magique, nous avons décidé que tout les secteurs commençant par 32 bits vallant 0 étaient considérés comme libres.
Ce choix a d'énormes problèmes, étant donné que la moitié du disque est réservé pour les inodes, la moitié du disque est perdu.
Cela a aussi un autre problème.
Etant donné que nous avons dû faire le changement au dernier moment, et que avant nous avions décidé que les secteurs de données auraient un nombre magique, nous avons décidé que tous les secteurs commençant par 32 bits vallant 0 étaient considérés comme libres.
Ce pauvre choix fait que si une donnée écrite commence par 32 bits vallant 0, alors le fs considèrera le secteur comme libre, et par conséquent, pourra y écrire le secteur de donnée d'un autre fichier dedans.
Le fait d'écrire les 32 bits vallant 0 dans un fichier fera donc beugger notre fs.
Le fait d'écrire les 32 bits vallant 0 dans un fichier fera donc beuguer notre fs.
\vspace{10pt}
\section{Les operations implémentés de rtfs}
\section{Les opérations implémentées par rtfs}
Nous n'avons jamais voulu que rtfs rivalises les systèmes de fichiers déjà existant, par conséquent, nous lui avons implémenté uniquement les opérations basiques.
En effet, si vfs nous permet d'implémenter des opérations pour le block super, des opérations différentes pour les inodes fichiers et dossier, voir même si on souhaites mettre des opérations différentes en fonction du numéro de nos inodes.
Vfs permet aussi d'implémenter une bonne quantité d'opérations pour les fichiers et les operations sur l'espace d'addresses des fichiers.
Enfin, il permet de d'implémenter des opérations sur les dentry.
Bien que tout ca, nous n'avons implémenté aucune opérations sur le block super ou les dentry,
pour les inodes dossier, nous avons implémenté diverses opérations.
Nous n'avons jamais voulu que rtfs rivalise avec les systèmes de fichiers déjà existants, par conséquent, nous lui avons implémenté uniquement les opérations basiques.
En effet, si vfs nous permet d'implémenter des opérations pour le block super, des opérations différentes pour les inodes fichiers et dossiers, voire même si nous souhaitons mettre des opérations différentes en fonction du numéro de nos inodes.
Vfs permet aussi d'implémenter une bonne quantité d'opérations pour les fichiers et les operations sur l'espace d'adresse des fichiers.
Enfin, il permet d'implémenter des opérations sur les dentry.
Nous ne parlerons pas des dentry dans ce document étant donné que vfs le gère à notre place.
La seule fois où nous avons dû nous en servir a été au moment ou il fallait indiquer à vfs que nous devions créer un nouvel inode sur le disque.
Bien que tout ça, nous n'avons implémenté aucune opérations sur le block super ou les dentry.
Pour les inodes dossier, nous avons implémenté diverses opérations.
\begin{itemize}
@ -39,16 +41,16 @@
\item L'opération mkdir permettant de créer d'autres inodes dossiers dans un inode dossier
\item L'opération lookup permettant à vfs de rechercher un inode dans un inode dossier connaissant son nom
\item L'opération lookup permettant à vfs de vérifier la présence d'un inode dans un inode dossier connaissant son nom
\end{itemize}
Vfs consifère qu'un inode pointe sur un fichier générique.
Ainsi, un dossier à aussi des opérations de fichier.
Vfs considère qu'un inode pointe sur un fichier générique.
Ainsi, un dossier a aussi des opérations de fichier.
Nous avons décidé de lui en implémenter une seule.
La seule absolument nécéssaire pour que un dossier soit un dossier : \verb|iterate_shared|, qui permet de parcourir un dossier pour retourner le nom et le numéro des inodes référencé par le dossier.
La seule absolument nécéssaire pour qu'un dossier soit un dossier : \verb|iterate_shared|, qui permet de parcourir un dossier pour retourner le nom et le numéro des inodes référencés par le dossier.
Voici ainsi toutes les opérations que nous avons implémentés pour un dossier.
Voici ainsi toutes les opérations que nous avons implémentées pour un dossier.
\begin{center}
@ -56,8 +58,8 @@
\end{center}
Nous avons choisi de ne pas implémenter d'opérations d'inodes sur les inodes de fichiers, mais uniquement des opérations de fichiers et des operations d'espaces d'addressages.
En effet, de notre point de vue, pour que un fichier soit un fichier, au minimal, il doit être possible d'y écrire dedans, et de lire ce que l'on à écrit dedans.
Nous avons choisi de ne pas implémenter d'opérations d'inodes sur les inodes de fichiers, mais uniquement des opérations de fichiers et des opérations d'espaces d'adressages.
En effet, de notre point de vue, pour qu'un fichier soit un fichier, au minimal, il doit être possible d'y écrire dedans, et de lire ce que l'on à écrit dedans.
Ainsi, nous avons implémenté comme opérations sur le fichier uniquement :
\begin{itemize}
@ -68,12 +70,12 @@
\item llseek, permettant de changer la position du pointeur dans le fichier.
\item mmap, comme memory map, cela n'était pas nécessaire d'être implémenté, mais puisque cela réutilisait que des fonctions que l'on avais déjà réalisé plus quelques fonctions kernel, et que c'est notament utilisé pour accélérer la lecture et l'écriture des données, nous l'avons implémenté.
\item mmap, comme memory map, cela n'était pas nécessaire d'être implémenté, mais puisque cela réutilisait uniquement des fonctions que l'on avait déjà réalisées plus quelques fonctions noyau, et que c'est notamment utilisé pour accélérer la lecture et l'écriture des données, nous l'avons implémenté.
\end{itemize}
Chaqu'une de ces opérations sur les fichiers nécessitent que l'on implémentes leurs opérations réspéctives.
Dans notre cas, nous avons du implémenter les opérations suivantes :
Chacune de ces opération sur les fichiers nécessitent que l'on implémente leurs opérations réspéctives.
Dans notre cas, nous avons dû implémenter les opérations suivantes :
\begin{itemize}
@ -91,28 +93,29 @@
\end{itemize}
Ce qui nous donne, si on en fait un schémat pour répertorier toutes les opérations possibles sur un fichier :
Ce qui nous donne, si on en fait un schéma pour répertorier toutes les opérations possibles sur un fichier :
\includegraphics[width=450pt]{rtfs_file_operations.drawio.png}
L'opération bmap permet de mapper en mémoire deux blocks, c'est à dire lier deux espaces d'addressages de mémoire entre eux.
L'opération bmap permet de mapper en mémoire deux blocks, c'est à dire lier deux espaces d'adressages de mémoire entre eux.
Elle est nécessaire parce que l'opération mmap à été implémentée.
L'opération lire folio permet de lire les pages déjà chargés par le vfs, par conséquent sans nécessiter de les lire à nouveau sur le disque.
L'opération lire folio permet de lire les pages déjà chargées par le vfs, par conséquent sans nécessiter de les lire à nouveau sur le disque.
\vspace{10pt}
\section{Ce qui aurrait du être fait pour pallier à ses défaults.}
\section{Ce qui aurait dû être fait pour pallier à ces défauts.}
Rtfs possède plein de défaults.
Les défaults sur lesquels on vas se concentrer sont les problèmes liés à notre approche, c'est à dire définir que les secteurs sont occupés si ils ont un nombre magique en leur début.
Une manière beaucoup plus efficiente, et surtout qui n'aurrait pas pu avoir le même bug, aurrait été de réserver plusieurs secteurs juste après le block super pour garder trace des secteurs libres.
Chaques bits dans cette zone représenterait un secteur, si le bit vaut 0, cela signifie que le secteur est libre et si le bit vaut 1 veut dire que le secteur est occupé.
En autre défault que l'on peut se pencher dessu est la fragmentation.
Rtfs possède plein de défauts.
Les défauts sur lesquels on va se concentrer sont les problèmes liés à notre approche, c'est à dire définir que les secteurs sont occupés s'ils ont un nombre magique en leur début.
Une manière beaucoup plus efficiente, et surtout qui n'aurait pas pu avoir le même bug, aurait été de réserver plusieurs secteurs juste après le block super pour garder trace des secteurs libres.
Chaque bit dans cette zone représenterait un secteur, si le bit vaut 0, cela signifie que le secteur est libre et si le bit vaut 1 veut dire que le secteur est occupé.
En autre défaut que l'on peut se pencher dessus est la fragmentation.
En effet, le mécanisme actuel d'avoir tout les secteurs pairs des données et tout les secteurs impairs des inodes est vraiment horrible.
Encore, nous aurrions du faire comme ext2, et garder tout les inodes au même endroit, et toutes les données au même endroit sur le disque.
Les inodes devraient quoi qu'il arrive, plutôt qu'être différenciés en dossiers et en fichiers, tous avoir la même nature, c'est à dire pointer sur des données de la même manière, et c'est la manière que l'on lit les données sur lesquels ils pointent qui serait importante.
Encore, nous aurions dû faire comme ext2 et garder tous les inodes au même endroit, et toutes les données au même endroit sur le disque.
Les inodes devraient quoi qu'il arrive, plutôt qu'être différenciés en dossiers et en fichiers, tous avoir la même nature.
C'est à dire pointer sur des données de la même manière, et c'est la manière qu'on lit les données sur lesquelles ils pointent qui serait importante.
\end{document}

2
02_rapport_sur_les_filesystemes/parts/references.tex
View file

@ -4,7 +4,7 @@
\begin{document}
\chapter*{Refenrences}
\chapter*{Références}
\addcontentsline{toc}{chapter}{References}
{