Systèmes d'exploitation

Excellente question, merci de l'avoir posée :-)

Tout d'abord, en règle générale, il vaut mieux comparer EXt3 à NTFS, plutôt que EXT2, du fait que EXT2 n'offre pas de journalisation.

Deuxièmement, je suppose que la question porte sur la fragmentation externe. Dommage, puisque pour la fragmentation interne, la réponse est plus simple. Pour la fragmentation interne, NTFS a un léger avantage sur EXT3, pour deux raisons :

1. La fragmentation interne est directement liée à la taille des clusters/blocks. Or NTFS gère des clusters de 521 octets à 4 Kio, tandis que EXT3 exige des tailles de blocks de 1Kio à 4Kio. Petit bémol, tout de même, les clusters de 512 octets ne sont utilisables sur de petits disques (ou partitions).
2. Par ailleurs, NTFS a cet avantage sur EXT2-EXT3 de pouvoir stocker le contenu de touts petits fichiers (ceux qui génèrent le plus de fragmentation interne) directement dans les enregistrements de la MFT ce qui évite de « gaspiller » un cluster.

Pour la fragmentation externe l'analyse est plus délicate, surtout qu'il se télescopent souvent le système de fichier à proprement dire (structuration physique sur le disque et modalités d'accès), et des « effets de bord » induits par une utilisation intelligente de ces structures dans les pilotes ou modules de noyau mettant en oeuvre les algorithmes d'accès. Dans les documents traitant du problème on observe souvent une confusion entre les deux. Il devient encore plus complexe de faire la distinction entre les deux lorsqu'on se pose la question de l'impact de la fragmentation sur la performance globale des opérations de lecture et d'écriture.

Je ne pense pas qu'il y ait une raison fondamentale, dans l'architecture, que EXT ou NTFS soient différents pour ce qui concerne la fragmentation, pour la simple raison qu'ils se basent sur un principe similaire de structures d'indirection (arbres d'inodes dans le cas d'EXT) une structure similaire pour le cas de NTFS. Là ou, d'emblée, NTFS a une avance sur EXT est le concept de « runs » ou « extents » là où les structures d'indirection des inodes EXT adressent des blocs individuels. En théorie, il est possible qu'une mise en oeuvre d'un pilote EXT peu optimisée fasse que les blocs successifs (au sens inode) ne le soient pas vraiment sur disque (= fragmentation) ce risque est réduit pour NTFS puisqu'on cherche à allouer des ensembles consécutifs de clusters (les fameux runs) en fonction des besoins. Mais c'est la théorie. En pratique, les implantations de pilotes EXT vont faire de l'allocation par anticipation, essayant d'allouer tous (ou partie) les blocs d'accès direct d'un inode ou d'un bloc d'allocation indirect en une fois et de façon contigüe sur le disque. De même, pour NTFS, le paramètre gérant la taille par défaut des runs a une influence non négligeable également.

Ce qui faut en retenir c'est que les deux approches permettent de faire de la lecture anticipée. Lorsqu'un processus a besoin d'accéder à un bloc/cluster, la probabilité qu'il ait également besoin d'accéder au bloc/cluster suivant (au sens des inodes) est assez grande. De fait, les implantations des pilotes lisent systématiquement n blocs/clusters suivants rendant (en général) les deux approches robustes à une fragmentation raisonnable.

Il y a toutefois un effet de bord un peu délicat qui dépend fortement des choix d'implantation. Le principe des runs NTFS rend le système particulièrement intéressant pour l'insertion de données en milieu de fichier (surtout si les fichiers sont très gros). Dans un arbre à inodes, l'insertion de données requiert la modification de tous les pointeurs d'indirection, puisqu'ils adressent des blocs individuels et tous les blocs se trouvent décalés. En revanche, en théorie, seul le run dans lequel on insère doit être modifié, dans le cas NTFS. Dans le cas de EXT, comme on doit tout ré-allouer, on allouera des séquences de blocs en fonction de la fragmentation du disque : si le disque est proche de la saturation, la fragmentation risque d'augmenter ; en revanche, lorsque le disque est peu saturé, il y a de fortes chances que la fragmentation diminue (puisque le fichier se trouvera physiquement déplacé là où l'on aura pu allouer les blocs consécutifs). En revanche (sauf surcharge significatif et algorithmiquement assez lourd du pilote) NTFS n'aura pas tendance à remettre en cause la structure des runs existants, hormis le run courant. Et là deux cas de figure se présentent : soit il y a assez de place pour allouer un nouveau run de taille suffisante, et la fragmentation ne sera pas affectée, soit il faut scinder le run en deux (ou plus parties) et la fragmentation augmente. Or, une fois un run scindé, il ne sera jamais ré-assemblé. On peut en déduire que (dans des cas généraux et hors situations pathologiques) EXT aurait tendance à s'auto-défragmenter tant que le disque n'arrive pas à une situation de saturation (et a une possibilité de revenir à une situation quasi-optimale à partir une situation très fragmentée et saturée). En revanche, NTFS ne peut qu'avoir un niveau de fragmentation croissant, même si celui-ci peut être extrêmement faible si le disque n'arrive pas proche de la saturation.

Cela reste toutefois une discussion théorique, car je ne suis pas sûr que NTFS permette effectivement une insertion « intelligente » sans réécrire la totalité du fichier.

Bart