Je crois que personne connaissant tant soit peu les systèmes d'exploitation (SE) et plus spécialement l'implémentation des systèmes de fichiers (SF) n'a jamais dit que la fragmentation n'existe pas, que ce soit sous Linux ou tout autre système dit "moderne".
Pour retrouver des SF n'ayant aucune fragmentation, il faut revenir aux années 1970 et au SE OS/VS d'IBM. Ce SF utilisait des unités d'allocations de taille et d'implantation physique fixes (allocation dite contiguëe) déterminées à la création du fichier. Mais quelle joie pour l'administrateur système de savoir où implanter un fichier (en terme de cylindre-piste) dans une installation qui pouvait comporter plusieurs milliers de fichier ! Et cette absence de fragmentation se payait par la nécessité de connaître, au moment de la création du fichier, la taille maximum que celui-ci pouvait atteindre. On imagine aisément le gaspillage de place disque, surtout à l'époque où une capacité de 128 Mo sur disque était considérée comme le summum du confort. Mais il y avait, pour les grandes installations, des batteries impressionnantes d'unités de disques.
S'il est vrai que la quasi totalité des SF actuels (à ma connaissance et en dehors des SF temps réels devant répondre à des spécifications rigoureuses en terme de temps d'accès disque) travaillent en allocation chaînée (FAT en est une variante dégénérée) ou en allocation indexée (cas de Linux). Ces types d'allocations souffrent, intrinséquement, de fragmentation.
Maintenant reste à voir l'effet de cette fragmentation sur l'efficacité du traitement:
- Sous Windows (et ses dérivés / clones), les lectures / écritures se font selon l'organisation LOGIQUE des données, indépendamment de leurs positions PHYSIQUES sur le disque. Dès lors, il s'ensuit de nombreux déplacement des têtes d'accès en cas d'un taux de fragmentation relativement grand.
Il existe bien un tampon, dont on peut se demander à quoi il sert d'ailleurs. D'ailleurs, si je me souviens bien (mes dernières utilisation de Windows remontent à plusieurs années), si l'on augmente la taille du tampon a cela d'une certaine limite, les performances diminuent, un effet "marrant" qui fait se "bidonner" les spécialiste des SE.
- Sous Linux (Unix et ses dérivés / clones), les lectures / écritures se font selon l'organisation PHYSIQUE des données à partir du tampon. Dès lors, les déplacement des têtes d'accès sont limités drastiquement.
C'est, en fait, un peu plus complexe avec les disques de grande capacité. En effet, à cause de certaines restrictions du BIOS (adresse en cyl-track-sector avec nombre de bits limités), la géométrie physique que "voit" le SE n'a que peut de rapport avec la géométrie physique effective des disques et cela tant que l'adressage se fera en termes absolus (cyl-track-sector) et non pas en terme relatifs (origine+déplacement notés en nombre de secteurs ou, mieux, en nombre de blocs de taille modifiable).
Au surplus, sous Linux, l'allocation d'un nouveau bloc disque à un fichier se fait selon un algorithme qui tend à minimiser la distance physique de ce bloc des autres blocs du fichier.
Par contre, il est parfaitement vrai que cet algorithme perd de son efficacité avec l'augmentation du taux de remplissage du disque (plus difficile de trouver un bloc, ou un ensemble de blocs, contiguës !).
Si, par ailleurs, la taille du tampon est réduite, l'optimisation des déplacements se fera sur un nombre de blocs plus petit et sera par conséquent moins efficace. À la limite, pour un tampon d'un seul bloc, on se trouve ramené au cas de la mise à jour en ordre logique.
Sous Linux, la taille du tampon est automatiquement ajustée en fonction des processus en mémoire.
Donc, sous Linux, mémoire physique relativement faible, nombreux processus actifs, disque presque plein se conjuguent pour diminuer l'efficacité. Mais, amha, ce sont des conditions limites, qui impliquent (si les moyens financiers le permettent) achat de mémoire et / ou de disques.
Et se sont des conditions qui, sous Windows, plantent totalement le système.
# Un mythe, vraiment ?
Posté par abgech . En réponse au journal Fait n°1 : Linux n'est pas sujet à la fragmentation.... Évalué à 10.
Pour retrouver des SF n'ayant aucune fragmentation, il faut revenir aux années 1970 et au SE OS/VS d'IBM. Ce SF utilisait des unités d'allocations de taille et d'implantation physique fixes (allocation dite contiguëe) déterminées à la création du fichier. Mais quelle joie pour l'administrateur système de savoir où implanter un fichier (en terme de cylindre-piste) dans une installation qui pouvait comporter plusieurs milliers de fichier ! Et cette absence de fragmentation se payait par la nécessité de connaître, au moment de la création du fichier, la taille maximum que celui-ci pouvait atteindre. On imagine aisément le gaspillage de place disque, surtout à l'époque où une capacité de 128 Mo sur disque était considérée comme le summum du confort. Mais il y avait, pour les grandes installations, des batteries impressionnantes d'unités de disques.
S'il est vrai que la quasi totalité des SF actuels (à ma connaissance et en dehors des SF temps réels devant répondre à des spécifications rigoureuses en terme de temps d'accès disque) travaillent en allocation chaînée (FAT en est une variante dégénérée) ou en allocation indexée (cas de Linux). Ces types d'allocations souffrent, intrinséquement, de fragmentation.
Maintenant reste à voir l'effet de cette fragmentation sur l'efficacité du traitement:
- Sous Windows (et ses dérivés / clones), les lectures / écritures se font selon l'organisation LOGIQUE des données, indépendamment de leurs positions PHYSIQUES sur le disque. Dès lors, il s'ensuit de nombreux déplacement des têtes d'accès en cas d'un taux de fragmentation relativement grand.
Il existe bien un tampon, dont on peut se demander à quoi il sert d'ailleurs. D'ailleurs, si je me souviens bien (mes dernières utilisation de Windows remontent à plusieurs années), si l'on augmente la taille du tampon a cela d'une certaine limite, les performances diminuent, un effet "marrant" qui fait se "bidonner" les spécialiste des SE.
- Sous Linux (Unix et ses dérivés / clones), les lectures / écritures se font selon l'organisation PHYSIQUE des données à partir du tampon. Dès lors, les déplacement des têtes d'accès sont limités drastiquement.
C'est, en fait, un peu plus complexe avec les disques de grande capacité. En effet, à cause de certaines restrictions du BIOS (adresse en cyl-track-sector avec nombre de bits limités), la géométrie physique que "voit" le SE n'a que peut de rapport avec la géométrie physique effective des disques et cela tant que l'adressage se fera en termes absolus (cyl-track-sector) et non pas en terme relatifs (origine+déplacement notés en nombre de secteurs ou, mieux, en nombre de blocs de taille modifiable).
Au surplus, sous Linux, l'allocation d'un nouveau bloc disque à un fichier se fait selon un algorithme qui tend à minimiser la distance physique de ce bloc des autres blocs du fichier.
Par contre, il est parfaitement vrai que cet algorithme perd de son efficacité avec l'augmentation du taux de remplissage du disque (plus difficile de trouver un bloc, ou un ensemble de blocs, contiguës !).
Si, par ailleurs, la taille du tampon est réduite, l'optimisation des déplacements se fera sur un nombre de blocs plus petit et sera par conséquent moins efficace. À la limite, pour un tampon d'un seul bloc, on se trouve ramené au cas de la mise à jour en ordre logique.
Sous Linux, la taille du tampon est automatiquement ajustée en fonction des processus en mémoire.
Donc, sous Linux, mémoire physique relativement faible, nombreux processus actifs, disque presque plein se conjuguent pour diminuer l'efficacité. Mais, amha, ce sont des conditions limites, qui impliquent (si les moyens financiers le permettent) achat de mémoire et / ou de disques.
Et se sont des conditions qui, sous Windows, plantent totalement le système.