sombrero a écritcomme quelqu'un l'a dit auparavant, ça serait utile de pouvoir indiquer une taille maximale de fichier à défragmenter car ça rallonge considérablement la durée (et inversement une taille minimale de fichiers lorsqu'on souhaite défragmenter uniquement les gros fichiers)
Je suis en train de réfléchir à tout ça. Pour l'instant, je pense qu'une limite de fragmentation par Mo me semble plus pertinente, mais rien n'empêche les deux.
sombrero a écrit- il faudrait même adopter une sorte de comportement automatique de cette taille maximale en fonction de l'espace disque restant. Par exemple inutile de chercher à défragmenter une image iso de 700 mo lorsqu'on n'a ne serait-ce qu'un voir 2 ou 3 Go disponibles, car le fichier restera extrêmement fragmenté quand même (et probablement beaucoup plus que ce qui l'était).
Je pense qu'il faut compter au moins 5x plus d'espace disque nécessaire libre pour espérer améliorer la défragmentation des fichiers > 10mo, et et bien plus encore pour les fichiers plus petits (dans ce cas vaudrait mieux afficher un avertissement car le résultat sera pire la plupart du temps).
Le problème est justement de pouvoir estimer l'espace libre nécessaire pour défragmenter correctement. Il n'y a pas vraiment de solution qui marche à tout les coups. On peut vouloir défragmenter un gros fichier de 1Go sur un disque de 100Go. Si des fichiers de 1ko se trouvent répartis tout les 100Mo, le gros fichier ne pourra jamais être complètement défragmenté (toujours au moins 10 morceaux). Pourtant, l'espace libre est de plus de 98% dans ce cas...
Au fait, n'oubliez pas que c'est un défragmenteur
naïf. Faire un "vrai" défragmenteur demanderait des algorithmes évolués, la lecture des tables d'inodes et tout et tout. Ca existe déjà sous Linux. L'avantage de ce script est qu'il travaille sur des partitions montées, peut travailler uniquement sur un répertoire, et ne déplace que les fichiers fragmentés. Pas besoin d'une partition aussi grande que la partition à défragmentér pour fonctionner.
sombrero a écritC'est encore plus vrai quand on voit dans le script que tu fais 2 copies (un buffer qui réduit d'autant l'espace disque disponible puis la copie de défragmentation). Donc peut-être à voir de ce côté là quitte à mettre une option pour forcer la défragmentation lorsque l'espace disque jugé nécessaire pour un fichier est insuffisant.
Je fais ces deux copies pour des raisons de sécurité. L'objectif est qu'il reste toujours au moins une copie du fichier, de sorte qu'en cas d'interruption brutale (genre panne de courant) on puisse récupérer ce fichier, avec l'option
-r.
J'ai bien conscience que ça diminue beaucoup les performances du script, mais pour l'instant je le laisse. Là aussi, je ferai peut-être une option pour le désactiver.
L'intérêt dans ce cas serait de faire une copie, et si elle est moins fragmentée, de remplacer l'original par la copie (remplacer le second
cp par
mv) et recommencer. Ca serait bien plus performant.
sombrero a écrit- faudrait empêcher (par défaut ou définitivement) la défragmentation de certains répertoires sensibles ou inutiles : /boot/, /proc/, /dev/ , /mnt/, /media/, tous les /lost+found/, /selinux/, /sys/, et probablement /tmp/ pour éviter les problèmes avec les programmes ouverts
Ca par contre, je suis un peu contre. D'abord par ce que c'est lourdingue à faire (je suis faignant), et ensuite parce que je pense que c'est la responsabilité de l'administrateur de ne pas tout casser (il faut
sudo pour lancer le script). La commande
rm par exemple, n'interdit pas de supprimer son dossier racine. Et bien pour moi, c'est la même chose.
Cela dit, Windows nous a habitué à utiliser le défragmenteur comme n'importe quel autre logiciel courant, et beaucoup de monde pourrait être tenté d'utiliser ce script aussi "naturellement" que le défragmenteur Windows.
Faire une telle liste et la justifier risque de demander pas mal de travail mais bon, si des volontaire veulent s'y essayer, je veux bien faire une option "blacklist" qui lit un fichier contenant les dossiers blacklistés.
sombrero a écrit- une grosse amélioration en terme de résultats mais complexe à mettre en place serait de commencer par les fichiers les plus petits pour libérer au fur et à mesure de plus en plus d'espace consécutif pour les plus gros fichiers
Ca c'est une excellente idée je trouve. Bash n'est peut-être pas très adapté pour faire ça (trier une liste des fichiers en fonction de leurs tailles... hummmm) mais je veux bien regarder.
Mais ça ne résout pas tout non plus. Dans l'exemple au dessus, si les fichiers de 1ko ne sont pas fragmentés, le script ne le déplacera pas, et le problème reste insoluble. Sauf si le système profite de déplacer un fichier pour en déplacer d'autres (voir plus bas).
sombrero a écrit- sinon comme tu l'as soulevé, j'ai très souvent des fichiers de quelques mos qui sont parfois beaucoup beaucoup plus fragmentés qu'à l'origine (genre de 20 à 250 fragments). C'est encore plus bizarre lorsqu'un fichier de même taille juste après (style série de photos enregistrées au même moment) voit sa défragmentation considérablement réduite partiellement ou entièrement... Mais ça tu n'y peux rien du tout je pense 🙂 Je suis quand même très surpris, d'autant plus que j'ai fait les tests avec + de 8 Go de libre (en ext3)
Dans le même genre, j'ai des fichiers issus d'une même archive compressée qui sont parfois très (très) fragmentés, alors que pourtant les autres fichiers de l'archives ne le sont pas.
sombrero a écrit- dans le même ordre de surprise, je ne comprend pas réellement pourquoi il faut parfois plusieurs copies pour défragmenter un fichier, vu que le système de fichiers est censé dès la première copie trouver le meilleur emplacement sur le disque pour placer le fichier (notamment un endroit pour stocker le fichier en une seule fois).
Je vois trois explications (je pense à la 1):
* Ou bien, lorsqu'on déplace un fichier, le système en profite pour déplacer d'autres fichiers.
* Ou bien l'algorithme cherche un bon endroit pour placer le fichier, qui n'est pas forcément le meilleurs, mais qui demande peu de temps à être trouvé. Une bonne solution, mais qui n'est pas optimale car ça mettrait trop de temps à être trouvé. Cet algorithme utilise peut-être un peu de hasard pour fonctionner.
* Ou bien un bug 🙂 mais ça me semble plus probable pour la remarque au dessus.
sombrero a écrit- rajouter une possibilité de stopper proprement la défragmentation pour éviter les mauvaises surprises. Je sais pas si c'est possible, mais faudrait capturer une combinaison de touches au clavier et quand elle est saisie le script termine la défragmentation du fichier en cours et s'arrête.
Bonne idée aussi, je vais regarder ça.
