Hello, voici donc une petite explication sur ce qu'est l'ext2...
 
Pas dans de GRANDS details sournois, mais les notions de base pour savoir comment ca amrche en gros... Les experts sursauteront surement a certains endroits, mais restez indulgent, j'essaie de rester accessible...
 
Je vous conseille ENORMEMENT de lire et de comprendre la FAT de mlicrosoft, que j'ai expliquée sur hardware, avant de venir comprendre ce qui se passe ici : le niveau est nettement plus élevé !
 
http://forum.hardware.fr/forum2.ph [...] ic=&trash=
 
Le début est le meme, pour des raisons de cohérence, et histoire d'avoir tous les termes expliqués dans le meme article.
 
 

• 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 :
 

 
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).
 

 
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 :
 

 
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 :
 

 
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 :
 

 
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]

Moui,
 
soit un fichier de 256*256 entree (deja il est gros le fichier)
 
Ca fait 1+256*(256+1)*64 octets (en comptant que le nb de secteurs est codé sur 64 octets, soyon large) pris pour les inodes.
 
Soit 4 meg d'inode
Pour un fichier de 256*256*4 Ko (un bloc=4k)
Soit 4 To de fichier
 
Ils sont ou les  30 % ??

ca chais pas !
 
J'ai pas calculé, je l'ai lu, c'est tout, ca me parassait bcp mais bon
 
Pour la fat j'ai fait le calcul mais la la flemme !
 
Bref, le file system de windows a a peu pres autant de qualités que celui de nux

60 views mais pas trop de réactions...
 
J'ai perdu mon temps avec ce post ou quoi ?

Tetedeiench a écrit a écrit :   Bref, le file system de windows a a peu pres autant de qualités que celui de nux

 
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.

 
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%

oui, moi je voulais savoir comment sont rangés les inodes...
et j'ai trouvé ça :
http://www.programmationworld.com/ [...] cours1.htm
(une URL vaut mieux qu'on long discours)
 
et j'ai aussi trouvé une doc ...hum... bien brutale pour ceux qui veulent en savoir plus sur ext2fs :
http://e2fsprogs.sourceforge.net/ext2intro.html
c'est en anglais.
 
en tout cas merci tetedeiench.

 
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...

 
si vous etes trop con, passez votre chemin  

up !
Tout aussi clair que l'explication de la fat.
Et l'NTFS dans tout ça ?

J'ai appris que Ext2fs avait été mis au point par Rémi Card (mon prof de TCP/IP).  
J'aurais jamais pensé qu'un mec déconneur comme ca puisse faire des choses aussi surprenantes !

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

, en effet
 
Le NTFS, j'ai pas encore matté, mais je vais devoir le faire bientot, donc je posterai comment ca amrche !
 
je viens d'étudier des dinosaures de chez IBM CT fendart !
 
Dans l'un les fichiers devaient etre contigus ( Aucune fragmentation). Sympa comme idée sauf quand tu rallonge un fichier et qu'il y a plus de place.
 
Dans l'autre les fichiers faisaient un bloc défini (style 4 secteurs) et tu rajoutais  a leur bout des secteurs d'extension, style 2 secteurs, la ou tu pouvais sur le disque...
 
Le bordel niveau fragmentation, utilisation (car tailles fixes), mémoire prise et tout (je détaille pas la struct mais bon... BIG struct )
 
Bref

Si, facilement meme...
 
Ca dépend de la taille de tes clusters... si Y font 1Ko ben...

Oui, oui, oui !!!  
Quels ont été les évolution pour arriver à l'ext 2 ?
 
Parceque dans un bouquin sur UNIX vieux d'il y a 15 ans ! Ct deja  géré pareil ! alors, qu'est ce qu'ils ont ajouté ???
 
Et l'ext3 (installable sous RedHat 7.2, je sais je l'ai !)
C quoi la difference avec l'ext2 ???

Up ext3 ?????

Ext2 ressemble beaucoup à ufs et au système de fichiers minix, c'est clair. Je pense qu'ils ont surtout refait quelque chose de plus propre, et de moins limité (taille et nombre des fichiers, par exemple).
 
Pour ce qui est d'ext3, il est strictement identique à ext2, à l'exception d'un fichier nommé .journal à la racine, et qui contient les informations de journalisation.