Apparement les modérateurs ont ajouté à ma proposition initiale de dépêche un lien qui présente pourquoi Linux n'a pas besoin de défragmentation.
De mon point de vue, cet article est dans le vrai : dans la quasi-totalité des cas le système de fichier sait se débrouiller tout seul.
ShaKe vise précisement à déceler les seuls cas où le système de fichier échoue.
Il y en a au moins trois :
Premièrement, le cas où le disque est trop plein. Lors de la présentation à mes profs (à la base c'est un projet d'étude à Lyon1), j'avais fourni une image de filesystem qui faisait bien ressortir le problème : http://vleu.net/shake/disk.bin.bz2 . Sur cet exemple (très articiel), les fichiers "gros" (un méga si je me rappelle bien) passaient d'un millier de fragments à quelques uns. Le cas de cet utilisateur montre que ça arrive aussi dans la vraie vie http://forums.gentoo.org/viewtopic-t-463204-postdays-0-posto(...) .
Ensuite, les "fichiers sparses". Quand un programe Linux accède par exemple au 60ème méga octet d'un d'un fichier qui n'en fait que 5, le système de fichier ne génére pas un fichier plein de zeros pour "remplir le trou" mais "saute par dessus". On a alors systèmatiquement deux fragments. C'est une fonctionalité très interessante puisqu'elle fait gagner une quantitée non négligeable d'espace disque. Mais les logiciels de peer to peer (notament) lui causent problèmes car il reçoivent les morceaux dans un ordre plus ou moins aléatoire, ce qui cause de nombreux sauts et une fragmentation importante. Shake détecte ces sauts injustifiés, mais aussi ajoute des sauts dans le cas où il seraient utiles.
Enfin, il y a le problème de l'évolution de la taille et de l'usage des fichiers. ReiserFS (extN aussi je suppose) semble s'arranger pour placer les fichiers d'un même dossier ensemble, et dans l'ordre d'écriture. Mais aussi intelligent soit-il, le système ne peut pas anticiper deux ans d'utilisation, et si par exemple un dossier se voit ajouter une centaine de fichiers après être longtemps resté intact, ou si un fichier grossit sans cesse longtemps encore après avoir été crée, il seras bien obligé de fragmenter.
Il y a aussi d'autres choses, comme le fait que l'ordre d'écriture ne soit pas nécessairement l'ordre de lecture (shake réecrit les fichiers éloignés les un des autres dans l'ordre de lecture) et le fait que de nombreux fichiers restent "sur place" longtemps, fragmentant l'espace libre car le FS ne va pas de lui même les déplacer (shake les réecrit aussi).
Pour résumer : il y a des cas (rares) où les hypothèses que le système de fichier avait fait sur l'utilisateur, ou sur l'usage des fichiers sont fausses. Shake notifie le problème au système de fichier simplement en lui intimant l'ordre de les réecrire. L'efficacité du système de fichier sous jacent est donc justement ce qui fait marcher Shake et cet article va dans mon sens.
Par contre, s'il est donc suceptible d'être utile, ce n'est bel et bien pas au quotidien car ces cas sont rares.
# Re: Pourquoi Linux n'a pas besoin de défragmentation
Posté par un_brice (site web personnel) . En réponse à la dépêche ShaKe, un défragmenteur pour GNU/Linux. Évalué à 10.
De mon point de vue, cet article est dans le vrai : dans la quasi-totalité des cas le système de fichier sait se débrouiller tout seul.
ShaKe vise précisement à déceler les seuls cas où le système de fichier échoue.
Il y en a au moins trois :
Premièrement, le cas où le disque est trop plein. Lors de la présentation à mes profs (à la base c'est un projet d'étude à Lyon1), j'avais fourni une image de filesystem qui faisait bien ressortir le problème : http://vleu.net/shake/disk.bin.bz2 . Sur cet exemple (très articiel), les fichiers "gros" (un méga si je me rappelle bien) passaient d'un millier de fragments à quelques uns. Le cas de cet utilisateur montre que ça arrive aussi dans la vraie vie http://forums.gentoo.org/viewtopic-t-463204-postdays-0-posto(...) .
Ensuite, les "fichiers sparses". Quand un programe Linux accède par exemple au 60ème méga octet d'un d'un fichier qui n'en fait que 5, le système de fichier ne génére pas un fichier plein de zeros pour "remplir le trou" mais "saute par dessus". On a alors systèmatiquement deux fragments. C'est une fonctionalité très interessante puisqu'elle fait gagner une quantitée non négligeable d'espace disque. Mais les logiciels de peer to peer (notament) lui causent problèmes car il reçoivent les morceaux dans un ordre plus ou moins aléatoire, ce qui cause de nombreux sauts et une fragmentation importante. Shake détecte ces sauts injustifiés, mais aussi ajoute des sauts dans le cas où il seraient utiles.
Enfin, il y a le problème de l'évolution de la taille et de l'usage des fichiers. ReiserFS (extN aussi je suppose) semble s'arranger pour placer les fichiers d'un même dossier ensemble, et dans l'ordre d'écriture. Mais aussi intelligent soit-il, le système ne peut pas anticiper deux ans d'utilisation, et si par exemple un dossier se voit ajouter une centaine de fichiers après être longtemps resté intact, ou si un fichier grossit sans cesse longtemps encore après avoir été crée, il seras bien obligé de fragmenter.
Il y a aussi d'autres choses, comme le fait que l'ordre d'écriture ne soit pas nécessairement l'ordre de lecture (shake réecrit les fichiers éloignés les un des autres dans l'ordre de lecture) et le fait que de nombreux fichiers restent "sur place" longtemps, fragmentant l'espace libre car le FS ne va pas de lui même les déplacer (shake les réecrit aussi).
Pour résumer : il y a des cas (rares) où les hypothèses que le système de fichier avait fait sur l'utilisateur, ou sur l'usage des fichiers sont fausses. Shake notifie le problème au système de fichier simplement en lui intimant l'ordre de les réecrire. L'efficacité du système de fichier sous jacent est donc justement ce qui fait marcher Shake et cet article va dans mon sens.
Par contre, s'il est donc suceptible d'être utile, ce n'est bel et bien pas au quotidien car ces cas sont rares.