[File systems] L'ext2, Comment ca marche ? [Little cours inside]

[jfdsdjhfuetppo]--Message édité par MrAthlon--[/jfdsdjhfuetppo]

 
si vous etes trop con, passez votre chemin  :lol:

 
Soit tu parcours effectivement la FAT, et tu dois faire toute la case pour trouver le dernier secteur, soit tu fait 4 acces disque sous ext2 ...
 
Je pense personellement que aprcourir la table est plus intéressant : un acces disque est 1 000 000 de fois + lent qu'un accès mémoire...
 
Donc forcément...

 
Oui c'est ce qui semblerait logique...les gros inodes  n'existeraient que pour les fichiers concernes (les 10%)...du coup les 30% passeraient a 3%

 
Rien à voir.
Si tu veux une partie d'un fichier avec la FAT, tu dois parcourir toutes les inodes.
Par exemple si tu veux rajouter qq chose à la fin du fichier.
Le cache est encore plus indispensable que pour ext2.
 
Je ne me rapelle plus bien de mes cours de sys d'ex, mais il me semble que si le fichier est petit, il n'y a pas 3 vecteurs d'indirection mais uniquement le nombre qu'il faut (à vérifier).
Donc ça ne prends pas tant de place que ça.
Et puis 3 accès disques, ça n'est pas super lent comparé à la taille du fichier.
D'ailleurs dans tout les bench que j'ai pu voir, ext2 était plus performant qu'un systeme FAT.

• AGENCEMENT DES DONNEES SUR UN DISQUE DUR

C'est plutot simple, et meme intuitif. Un disque dur est une surface magnétique sur laquelle se déplace une tete de lecture / ecriture. Cette tete suit des pistes de forme ronde, ayant pour centre le centre du disque (logique), sur lesquelles se trouvent des données.
 
Des chemins si vous préférez.
 
Maintenant, contrairement aux idées recues, chaque piste Contient le MEME nombre de secteurs. EXACTEMENT le meme, qu'elle soit située au centre du disque, ou a la périphérie. Sa taille n'importe pas !
 
Seulement, un disque ca ne raisonne pas en octets, pour des raisons de simplification de la tache. Il raisonne en secteurs. Un secteur peux avoir une taille variable ( 1Ko, 2Ko, ... 256 o, 1 Mo, bref), et représente la quantité MINIMALE d'informations  a écrire ou a lire en un coup. Si on a besoin d 'un octet, on ne va pas lire JUSTE l'octet : on va lire le secteur entier. C'est un peu une unité de mesure si on veut.
 
Le schémma ci dessous illustre un dur fictif, avec 3 pistes et 4 secteurs /  piste :
 
http://perso.wanadoo.fr/tetedeiench/Disque.gif  
 
Désolé pour les schémas laids sous paint, mais j'ai un peu la flemme la...
 
Bref, ce disque est extremement petit, mais l'idée est bien évidemment la.
 
Seulement, il faut que  le disque sache sur quelle piste et sur quel secteur de la piste il doit aller... C'est pas tres pratique.
 
Donc on a déciéd de  numéroter les secteurs de 0 à n, n étant leur nombre maximal. par  exemple 0 à 150 . C'est la carte située sous le disque dur qui convertit le nombre envoyé par l'OS en piste/secteur de piste...
 
Simplement pour simplifier la vie aux developpeurs.
 
Donc voila comment est stockée en gros l'information sur le disque... seulement le disque, lui il enregistre certes des iunfos, mais n'a aucune idée de  leur cohérence : il ne sait pas que tel secteur appartient a tel fichier, ni autre...  
 
c'est la que Entre en jeu l'OS. C'est lui qui gère ca, de A à Z.
 
L'ext2 constitue une solution a ce probleme.
 

• L'EXT2

C'est un systeme de fichier assez étrange, et fait assez peur au début...
 
Faut pas avoir peur de la récurrence :)
 
Bref, allons y.
 
Tout d'abord, Unix/linux considère le disque dur comme composé de blocs, tout comme windows. Un bloc est un regroupement de secteurs, tout simplement. Par exemple, un bloc c'est 5 secteurs.
 
C'est juste histoire de subdiviser encore le disque... et de limiter la place en mémoire... bref.
 
l'ext2 apporte un acces DIRECT au fichier dans 90% des cas. En fait, décodé, il apporte un acces direct aux secteurs des fichiers PETITS. Dont la taille est inférieure a 10 blocs.
 
Et comme vous le savez tous, ceux ci sont tres nombreux sous unix/linux, et on y accede souvent, d'ou le 90% des cas.
 
La base de l'EXT2 est l'INODE. Un Inode est juste une petite table, stockée sur le disque, contenant 10 adresses de blocs de fichier, et de 3 vecteurs d'indirection.
 
Je vais y aller par étapes, ne vous inquiétez pas.
 
Prenons le cas d'un fichier petit ( < a 10 blocs).
 
http://perso.wanadoo.fr/tetedeiench/inode1.gif  
 
C'est un bete tableau, dont la première case contient le n° du premier bloc du fichier, la seconde le second bloc, etc...
 
Bref, le fichier ici représenté ( appelons le fichier1 ) , est constitué des blocs 6,15,20,9,12 dans l'ordre.
 
Rien de transcendental dans ce cas la.
 
Maintenant, les fichiers peuvent faire plus de 10 blocs, encore heureux. Mais, la table n'aura jamais plus de 10 entrées...
 
Comment on fait ?
 
C la qu'interviennent les VECTEURS D'INDIRECTION.
 
un mot barbare pour appeler une case, une donnée un peu spéciale : c'est un pointeur vers un tableau spécial.
 
ledit tableau possède 256 entrées, chacune pointant vers un nouveau bloc ... Il s'apelle Bloc D'indirection. Il se situe, lui, non pas en mémoire, mais SUR LE DISQUE.
 
Regardez  le shéma suivant :
 
http://perso.wanadoo.fr/tetedeiench/inode2.gif  
 
Avec ceci, on peut donc avoir des fichiers de 257 blocs... Chaque case du tableau pointe sur un Bloc...
 
Cependant, quand on est dans ce cas la, on est plus dans l'acces direct : pour acceder au bloc n°15 par exemple, on doit charger d'abord le Bloc d'indirection, avant d'avoir acces au bloc du fichier... Y a une étape a faire. On est deja dans les 10% non direct ici.
 
Si on veut plus ? C simple, on rajoute un vecteur d'indirection, mais encore plus spécial :
 
http://perso.wanadoo.fr/tetedeiench/inode3.gif  
 
On arrive a 65802 Blocs... ce qui est deja pas mal.
 
A ce stade, pour acceder a un bloc de la troisième partie du fichier, on doit lire le premier bloc d'indirection, puis le second, puis enfin le bloc correspondant : il y a ici 2 étapes .
 
Et si on en veut plus ? On utilise le 3ème vecteur d'indirection.
 
Encore plus abrabre, mais je suis certain que vous avez deja deviné comment ca marche :
 
http://perso.wanadoo.fr/tetedeiench/inode4.gif  
 
Ceci est un inode COMPLET, a savoir la table a 10 entrées et les 3 vecteurs d'indirection.
 
 
Ici, on atteint les 4 milliards de blocs... Si un bloc fait 1 Ko, ca fait des fichiers gros de 4096 Go... Y a de quoi faire !
 
mais si on tombe dans le vecteur d'indirection 3, on aura acces au bloc en 4 lectures disque... donc ca va etre extremement lent.
 
Heureusement, un systeme de cache est la pour optimiser tout ca, sinon, on serai un peu dans la merde ;)
 
Avantages :
 
-Tres peu de mémoire prise
 
-Acces direct dans 90% des cas
 
Inconvénients :  
 
-Systeme de cache quasi obligatoire pour les 10% des acces restant sous peine de lenteur
 
-Espace disque nécéssaire ENORME pour un fichier (bcp + que la fat ! on estime la place pour les inode et les tables a environ 30% du disque).
 
Voila, c'est a peu pres tout... si vous avez des questions, hésitez pas !

[jfdsdjhfuetppo]--Message édité par Tetedeiench--[/jfdsdjhfuetppo]