cep a écritÉdit : maintenant, si l'on veut vraiment défragmenter un fs, la meilleure solution "serieuse" est celle donnée par roger64 dans cette même section, c'est à dire de copier l'ensemble du fs sur un autre disque, refaire le fs, puis déplacer à nouveau les données sur le disque d'origine.
C'était justement ma première motivation pour faire ce script: Je n'avais pas les moyens de copier l'ensemble de mes partitions "ailleurs" pour les recopier ensuite proprement. Il me fallait quelque chose capable de manœuvrer dans un espace restreint (et sur une partition montée). L'idée de faire un script qui ne déplace
que les fichiers fragmentés vient de là. Il lui faut pour fonctionner autant de place que le plus gros des fichiers fragmentés existant.
Je ne suis pas allé voir les écris de T. Tso, mais j'ai pas mal fouiné dans la documentation donnée, en partant de l'article que tu donnes. Quel dommage que ça soit en anglais, j'y apprends plein de choses intéressantes. Par contre, je ne comprends pas trop pourquoi cet article en particulier (dont cette argumentation pour les clusters et contre les blocks) et qui va plutôt dans le sens de l'utilité de la défragmentation.
(ou alors j'ai vraiment rien compris)
Une remarque aussi, ces articles sont vieux (2005) et la technologie à certainement évoluée depuis. (ça parle pas mal de ext2)
J'ai trouvé ceci très intéressant:
As to that some more considerations: one is that there are three types of "fragmentation":
* inodes being far away from the directory that links to them;
* data blocks being far away from the inode or the metadata (like tree or indirect blocks) that extends from the inode;
* data (or metadata) blocks being far away from each other.
Honnêtement, je n'imaginais pas l'existence du premiers types de fragmentation. Le second oui, mais j'aurais pensé ses effets négligeables. Évidement, mon script met l'accent sur le troisième type de fragmentation, car c'est en effet le seul qu'il peut mesurer, avec
filefrag. Cela ne veut pas dire qu'il n'aide pas à résoudre les deux premiers types de fragmentations, c'est juste que je ne sais pas le mesurer. Donc peut-être que oui, peut-être que non. Si vous connaissez des outils similaires à
filefrag pour ces deux types de fragmentation, ou un méthode pour l'estimer je veux bien faire des tests.
L'idée du script est très simple: si un système de fichier est conçu pour se défragmenter à l'usage, alors faire du remue ménage dans les fichiers fragmentés devrait l'aider à se défragmenter.
Si ce n'est pas le cas, dans de bonnes conditions d'utilisation du disque (espace libre suffisant en particulier) c'est que quelque chose ne va pas dans la gestion du système de fichier, et ce quelque chose devra être corrigé un jour. Un script comme le mien peut d'ailleurs aider à mettre en lumières des choses étranges (problème soulevé par
sombrero par exemple).
Apparemment, la fragmentation à l'usage d'un système de fichier ext3 à un gros impacte sur les performances:
So for now the conclusion is: at least for ext3 with time the layout becomes rather fragmented, with extremly large impact on performance in at least some cases. The cost of seeking is so large that a raise in the non-contiguous percentage reported by fsck.ext3 from 1% to 13% involves a sevenfold decrease in sequential reading performance.
Dans le détail, ça donne:
For pure metadata based operations (find, fsck) the newly loaded version is roughly twice as fast; but for reading all the data it is seven times faster.
Ce qui est inquiétant dans tout ça, c'est que l'auteur n'a pas fait de manipulation particulière pour fragmenter un disque et faire ses tests, il a utilisée son propre disque, dont la fragmentation résulte de l'utilisation courante:
So I decided to take my main "root" filesystem, which is around 7GiB in size, and has been rather thoroughly mixed up by upgrades, spool work and so on [...]
Enfin, concernant le fait que:
cep a écritLa table des inodes, les mtime, ctime sont soumis à rude épreuve pendant la réalisation du script. Idem les md5sum éventuels, y compris ceux indispensables.
Je crois que ça reste raisonnable dans la mesure ou les fichiers fragmentés sont peu nombreux (regarde les exemples donnés dans ce thread). Au final, je pense que l'investissement est bénéfique pour le disque dur.
Ma conclusion:
To avoid this file systems should be regularly "straightened out" by dumping them to something and then copying them back file by file.
Là dessus, on est tous d'accord, on obtient une réorganisation optimale du disque dur en faisant un "copier/coller" de la partition complète. Malheureusement, ce n'est pas toujours possible.
Donc mon script trouve son utilité dans quelques cas bien particuliers:
* On ne dispose pas de la capacité de copier sa partition entièrement par copier/coller.
* On ne peut pas se permettre de la démonter pour travailler dessus.
* On veut éviter une manipulation lourde, et longue.
* On souhaite ne défragmenter que certains répertoires particuliers.
Et d'une manière générale quand une défragmentation rapide ou très localisée, même si elle n'est pas optimale, est suffisante. C'est plus simple de faire:
sudo n_defrag Documents/
que l'autre manipulation.
Cordialement
