Ubuntu-fr

pnprog

Re : Défragmenteur naïf

Bon, j'ai réussi, il fallait que j'écrive

sudo bash n_defrag.sh  /dossier

et non

sudo n_defrag.sh /dossier

Le diable est dans les détails...:)

Au temps pour moi, ce que j'ai écris dans le mode d'emploi est faut, pour lancer un fichier exécutable qui se trouve dans le répertoire courant, il fait entrer:

sudo ./n_defrag.sh /dossier

Je vais aller corriger ça tout de suite ! (fait)

Dernière modification par pnprog (Le 30/05/2008, à 09:59)

pnprog

Re : Défragmenteur naïf

Analyse results for /home/hardy
3253 files: 0 f/Mo (before: .03 f/Mo)
4 files were fragmented: 30.33 f/Mo
0 files are still fragmented

J'ai fait ca aussi sur la racine / , c'est très long (1h05 mais pour 138047 files: .06 f/Mo (before: .43 f/Mo) ) , et il y a quelques erreurs, mais c'est normal sur la racine /.

Moi aussi j'ai quelques erreurs, quand le script analyse le fichier /proc/

Erreur: filefrag can not analyse /proc/5721/mounts
Erreur: filefrag can not analyse /proc/5721/mountstats
Erreur: filefrag can not analyse /proc/5721/task/5721/mounts
Erreur: filefrag can not analyse /proc/acpi/event
Erreur: filefrag can not analyse /proc/sys/kernel/sched_nr_migrate
Erreur: filefrag can not analyse /proc/sys/net/ipv4/route/flush
Erreur: filefrag can not analyse /proc/sys/net/ipv6/route/flush

C'est pas tellement une erreur du script, mais une erreur de filefrag.
Dans le détail, ça donne:

sudo filefrag /proc/5721/mounts
open: Invalid argument

Ce qui n'est pas très parlant. (en tout cas pour moi)

Quand filefrag génère une erreur (peut-importe laquelle) le script s'en rend compte, affiche cette ligne (d'ailleurs, j'ai mélangé de l'anglais et du français...) et passe au fichier suivant. Je crois que Warning serait plus approprié que Erreur.

Et sinon, je crois que /proc/ c'est de la mémoire vive.

Dernière modification par pnprog (Le 30/05/2008, à 10:09)

sombrero

Re : Défragmenteur naïf

Bonjour,

tout d'abord bravo pour ce script, c'est très intéressant. Quelques remarques qui j'espère seront utiles :

- comme 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)

- 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). C'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.

- 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

- 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

- 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 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).

- 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.

Bon courage !

Dernière modification par sombrero (Le 30/05/2008, à 11:15)

---

Debian unstable sur MacBook Pro.

uboops

Re : Défragmenteur naïf

+1 pour les bonnes idées de sombrero

Et plutôt que:
sudo ./n_defrag.sh /dossier

mieux vaut, pour mesurer le temps écoulé en plus :
time sudo bash n_defrag.sh -t 0 /dossier
ou
time sudo ./n_defrag.sh -t 0 /dossier

(c'est toujours utile pour ce genre de manip.)

---

“Au lieu de faire que ce qui fût juste fût fort, on a fait que ce qui fût fort fût juste.” (Blaise Pascal).

roger64

Re : Défragmenteur naïf

Je sème la panique partout.

la commande avec time fonctionne parfaitement, c'est moi qui oubliait un argument.

Sorry folks

Dernière modification par roger64 (Le 30/05/2008, à 15:43)

---

Les écrits de Richard O'Monroy

llwynrt

Re : Défragmenteur naïf

bonjour

le sudo n'est pas indispensable pour lancer le script puisque sudo est déjà dans le script

result=$(sudo filefrag "$file" 2>> /dev/null)

du coup on peut écrire

n_defrag.sh -t 0 /dossier

Marie-Lyse

---

Les erreurs Windows, c'est un peu comme les rêves, il faut savoir les interpréter, parfois ça peut vouloir dire quelque chose !

meushi

Re : Défragmenteur naïf

si le sudo est dans le script ca veut dire qu'un mot de passe peut être demandé à tout moment alors, nan ?

en lancant le script avec des droits béton dès le début ya plus de soucis pour le reste des opérations du coup.

j'ai bon ou pas ?

edit: huhu j'aime bien cette ligne:

/home/meushi/.../....flv 3 .......... 8

j'ai pas compris ou il a fragmenté au lieu de défragmenter ?
re edit: oui là ca commence à être un peu plus gênant:

/media/ second dd /... /une video.mkv 150 .......... 231
/media/ second dd /... /une autre video.mkv 157 .......... 286

le disque en question a 6Go de libre, soit... arg ah oui, 2%, je le pensais pas si limite celui là. bon ca doit être parceque mon disque a les dents du fond qui baignent, fausse alerte j'ai rien dit.

par contre, suggestion: au lieu de placer ses buffer et recopie sur le bureau, puisqu'il a tous les droits le script, il pourrait pas se faire un dossier dans /tmp et y faire son bouzon ? ca ferait plus clean je pense.

Dernière modification par meushi (Le 30/05/2008, à 18:13)

---

mon blog

llwynrt

Re : Défragmenteur naïf

si le sudo est dans le script ca veut dire qu'un mot de passe peut être demandé à tout moment alors, nan ?

en lançant le script avec des droits béton dès le début y'a plus de soucis pour le reste des opérations du coup.

le mot de passe est demandé seulement une fois au lancement du script. le truc c'est que je mets tous mes scripts dans /home/llwynrt/bin et je les lance dans un terminal en tapant seulement le nom du script.
si je lance avec sudo ./n_defrag.sh /dossier, il me le trouve pas et faut que je fasse cd bin puis sudo ./n_defrag.sh /dossier. pas très pratique ...

Marie-Lyse

---

Les erreurs Windows, c'est un peu comme les rêves, il faut savoir les interpréter, parfois ça peut vouloir dire quelque chose !

uboops

Re : Défragmenteur naïf

-> Marie-Lyse
Dans ce cas comme ca (avec ou sans sudo alors) :
time sudo bash /home/llwynrt/bin/n_defrag.sh -t 0 /home

---

“Au lieu de faire que ce qui fût juste fût fort, on a fait que ce qui fût fort fût juste.” (Blaise Pascal).

llwynrt

Re : Défragmenteur naïf

-> Marie-Lyse
Dans ce cas comme ca (avec ou sans sudo alors) :
time sudo bash /home/llwynrt/bin/n_defrag.sh -t 0 /home

oui mais je préfère taper

time n_defrag.sh -t 0 /home

c'est quand même plus rapide

---

Les erreurs Windows, c'est un peu comme les rêves, il faut savoir les interpréter, parfois ça peut vouloir dire quelque chose !

pnprog

Re : Défragmenteur naïf

comme 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.

- 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.

C'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.

- 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.

- 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).

- 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.

- 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.

- 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.

Dernière modification par pnprog (Le 31/05/2008, à 11:00)

pnprog

Re : Défragmenteur naïf

le sudo n'est pas indispensable pour lancer le script puisque sudo est déjà dans le script

result=$(sudo filefrag "$file" 2>> /dev/null)

si le sudo est dans le script ca veut dire qu'un mot de passe peut être demandé à tout moment alors, nan ?

en lancant le script avec des droits béton dès le début ya plus de soucis pour le reste des opérations du coup.

j'ai bon ou pas ?

Je vais l'enlever du script, pour raison de portabilité (si quelqu'un veut utiliser ce script sur une autre distribution qui n'utilise pas sudo par exemple).
En fait, j'avais mis au début du script un test qui vérifie qu'on est bien admin. Donc normalement, le lancer sans sudo ne devrait pas marcher. Ca marche chez vous ???
Et puis c'est mieux de lancer un script en sachant qu'il nécessite les droits d'administrateur, plutôt que de lancer un script et se rendre compte qu'il demande les droits d'administrateurs.

par contre, suggestion: au lieu de placer ses buffer et recopie sur le bureau, puisqu'il a tous les droits le script, il pourrait pas se faire un dossier dans /tmp et y faire son bouzon ? ca ferait plus clean je pense.

En effet. Le script "fait son bouzon" dans le répertoire courant. Pour l'instant je laisse comme ça car cela permet de se placer sur une autre partition que les répertoires qu'on défragmente.
Par exemple, vu que mon /home/ à sa partition à lui, si je défragmente /var/ (qui est donc sur une autre partition) la defragmentation est plus efficace, car les fichiers sont recopiés sur une autre partition, puis supprimé de la première, avant d'y être recopiés.
A l'avenir, je ferai une option pour choisir où écrire les buffers.
(ça va m'en faire des options tout ça...)

j'ai pas compris ou il a fragmenté au lieu de défragmenter ?
re edit: oui là ca commence à être un peu plus gênant:

    /media/ second dd /... /une video.mkv 150 .......... 231
    /media/ second dd /... /une autre video.mkv 157 .......... 286

le disque en question a 6Go de libre, soit... arg ah oui, 2%, je le pensais pas si limite celui là. bon ca doit être parceque mon disque a les dents du fond qui baignent, fausse alerte j'ai rien dit.

Là c'est très bizarre par exemple. Les fichiers fragmentés sont sur un autre disque (et à fortiori sur une autre partition). Ce qui veut dire qu'au moment de ré-écrire le fichier sur ton disque, il y a plus d'espace libre pour l'écrire qu'avant (au moment de la suppression) car ton buffer se trouve sur le bureau. Le fichier ne devrait alors pas pouvoir être plus fragmenté qu'avant.
Et ça, ça me fait penser à un bug. Sauf si le système a profité de la suppression du fichier pour replacer d'autres fichiers sur le disque.

Dernière modification par pnprog (Le 31/05/2008, à 11:24)

cep

Re : Défragmenteur naïf

Vous voudrez bien m'excuser de ne pas avoir tout lu, mais seulement dans les grandes lignes.
Ce genre de script me fait me poser quelques questions sur son utilité réelle et son degré de fiabilité.

Il s'agit de travailler sur un fs monté, et avec des dossiers en service. Y compris /bin, /usr, /tmp, etc ?
Qu'en est-il des "trous" provoqués par toutes les copies/suppressions ? En réalité je me demande si au final le fs dans son ensemble ne sera pas un champ de gruyère propice à de multiples fragmentations pour les dossiers créés par la suite.
La table des inodes, les mtime, ctime sont soumis à rude épreuve pendant la réalisation du script. Idem les md5sum éventuels, y compris ceux indispensables.

En conclusion, je doute du bon fonctionnement de ce script pour la bonne santé du fs. Il faut asavoir aussi qu'une fragmentation inferieure à 15% est difficilement ressentie.
Voir aussi les options de montage des fs qui peuvent améliorer beaucoup plus leur fonctionnement, plutôt qu'une chasse effrénée à la fragmentation.

Cordialement.
cep

---

Mon Seen This

pnprog

Re : Défragmenteur naïf

Il s'agit de travailler sur un fs monté, et avec des dossiers en service. Y compris /bin, /usr, /tmp, etc ?

Chacun en fait l'usage qu'il veut. Effectivement, le lancer sur le répertoire racine n'est pas prudent, et l'avertissement est très clair. Personnellement, je vais plutôt l'utiliser sur mes données personnelles qui sont souvent très fragmentées car récupérées depuis Internet.
Mais aussi pour ma clef USB qui me sert en général à passer/récupérer des documents venant d'autres OS...

Par exemple, beaucoup de documentation que j'avais récupérée (format pdf et html) était très fragmentée, le temps d'ouverture des documents était très lent mais aussi trackerd et d'autres autre logiciels qui font des vignettes/aperçus (dont l'affichage dans nautilus) ramait un max avec. Personnellement, j'ai vraiment senti la différence.

Qu'en est-il des "trous" provoqués par toutes les copies/suppressions ?
En réalité je me demande si au final le fs dans son ensemble ne sera pas un champ de gruyère propice à de multiples fragmentations pour les dossiers créés par la suite.

Que système de fichier soit un champs de gruyère ne me semble pas du tout un problème. Je pense même que c'est ainsi que les développeurs l'ont voulu. Un nouveau fichier sera effectivement fragmenté si sa taille est plus grande que les trous de gruyères, mais dans ce cas le nombre de fragments restera faible en comparaisons de la taille du fichier (sauf si presque plus d'espace disponible).
C'est pour ça que je fais des mesures de "fragmentation par Mo": si le temps de déplacement de la tête de lecture du disque entre les fragments est négligeable par rapport au temps de lecture des données, alors que ce fichier soit fragmenté n'est pas un problème.

La table des inodes, les mtime, ctime sont soumis à rude épreuve pendant la réalisation du script. Idem les md5sum éventuels, y compris ceux indispensables.

Ca c'est vrai, mais c'est le propre de n'importe quel défragmenteur. Et le défragmenteur n'est pas un jouet, même si ce n'est pas ce à quoi nous a habitué Windows. Il ne faut pas en abuser, mais dans certains cas, c'est nécessaire.

Il faut asavoir aussi qu'une fragmentation inferieure à 15% est difficilement ressentie.

Que signifie 15% de fragmentation exactement ? Est-ce que 15% des fichiers sont fragmentés ? ou est-ce que les fichiers fragmentés représentent 15% du disque ? ou encore autre chose ?

Très cordialement
pnprog

uboops

Re : Défragmenteur naïf

-> Marie-Lyse
Dans ce cas comme ca (avec ou sans sudo alors) :
time sudo bash /home/llwynrt/bin/n_defrag.sh -t 0 /home

oui mais je préfère taper

time n_defrag.sh -t 0 /home

c'est quand même plus rapide

C'est vrai, mais comme on défragmente généralement seulement une ou deux fois par an, l'effort supplémentaire n'est pas sur humain (surtout en copier/coller).

---

“Au lieu de faire que ce qui fût juste fût fort, on a fait que ce qui fût fort fût juste.” (Blaise Pascal).

\\Ouranos//

Re : Défragmenteur naïf

Bah ça m'a l'air bien
Oui mais! Si le script se supprime lui-même, qu'est-ce qu'on fait?

---

Ubuntu facile, c'est :
- Dire "Bonjour"
- Lire la doc et les règles du forum avant de poster. Savoir poser une question intelligemment.
- Mettre des balises url autour des liens et un tiret à su.

cep

Re : Défragmenteur naïf

Que système de fichier soit un champs de gruyère ne me semble pas du tout un problème. Je pense même que c'est ainsi que les développeurs l'ont voulu. Un nouveau fichier sera effectivement fragmenté si sa taille est plus grande que les trous de gruyères, mais dans ce cas le nombre de fragments restera faible en comparaisons de la taille du fichier (sauf si presque plus d'espace disponible).
C'est pour ça que je fais des mesures de "fragmentation par Mo": si le temps de déplacement de la tête de lecture du disque entre les fragments est négligeable par rapport au temps de lecture des données, alors que ce fichier soit fragmenté n'est pas un problème.

Ce n'est pas aussi simple.
Je t'invite à lire plus en détail les caractéristiques de ext3, en particulier les écrits de T. Tso, de même que par exemple :
http://www.sabi.co.uk/Notes/linuxFS.html
http://www.sabi.co.uk/blog/anno05-4th.html#051010

Voir aussi les nouvelles dispositions de ext3 pour augmenter la compatibilité avec ext4.

Bonne continuation.
cep

É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.

Dernière modification par cep (Le 31/05/2008, à 15:24)

---

Mon Seen This

pnprog

Re : Défragmenteur naïf

É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.

Ce n'est pas aussi simple.
Je t'invite à lire plus en détail les caractéristiques de ext3, en particulier les écrits de T. Tso, de même que par exemple :
http://www.sabi.co.uk/Notes/linuxFS.html
http://www.sabi.co.uk/blog/anno05-4th.html#051010

Voir aussi les nouvelles dispositions de ext3 pour augmenter la compatibilité avec ext4.

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:

La 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

pnprog

Re : Défragmenteur naïf

Bah ça m'a l'air bien
Oui mais! Si le script se supprime lui-même, qu'est-ce qu'on fait?

Je ne suis pas sûr, mais je pense que le script est chargée en mémoire avant d'être exécuté/interprété. Donc même si tu le supprime pendant l'exécution, ça ne devrait pas poser de problèmes.
Et le script ne touche qu'aux fichiers fragmentés, or pour que le script, un fichier de moins de 10ko, soit fragmenté, tu serais vraiment dans un cas désespéré...

Par contre, un problème peut se poser avec le buffer. C'est un peu un scénario catastrophe mais bon:
* Si tu interrompes le script en cours d'exécution et qu'il reste le buffer sur le disque (l'option -r ne supprime pas le buffer, par prudence).
* Si ce buffer est justement fragmenté.
* Si tu lances le script sur un répertoire parent contenant le buffer.
* Si aucun fichier fragmenté n'est trouvé avant d'arriver au buffer.

Alors quand le script arrive au buffer, ça produit une erreur et l'ensemble des données de toute les partitions de tout les disques dur sont irrémédiablement supprimées.

Je vous avais bien dit de sauvegarder vos données

Non, plus sérieusement, il se produit des erreurs, aux moments ou le script va vouloir faire des trucs du genre:

cp buffer buffer
...

Mais rien de grave au final, et le script continue son exécution ensuite (testé).

Dernière modification par pnprog (Le 02/06/2008, à 19:38)

cep

Re : Défragmenteur naïf

Personne ne nie les méfaits de la fragmentation, méfaits qu'il faut tout de même relativiser en fonction de l'utilisation du fs. Par exemple, si l'on fait beaucoup de compilations sur un fs, on augmentera rapidement le taux de fragmentation.

Je n'ai pas trop le temps de reprendre tes arguments, mais si tu entrais plus en détail dans le fonctionnement ext2/3 tu verrais qu'il y a quelques "inexactitudes".

Concernant la possibilité de voir la fragmentation d'un fs, justement sur les pages données en références, si tu les a lues, on y site un utilitaire, davtools. Je te laisse chercher les pages le concernant, de même que les liens pour un download.

Cordialement.
cep

---

Mon Seen This

pnprog

Re : Défragmenteur naïf

Concernant la possibilité de voir la fragmentation d'un fs, justement sur les pages données en références, si tu les a lues, on y site un utilitaire, davtools. Je te laisse chercher les pages le concernant, de même que les liens pour un download.

Oui j'avais bien vu davtool, mais il n'est pas dans les dépôts :-(
Je le compilerai peut-être (je suis pas à l'aise avec ces choses là), mais pas maintenant (il est tard chez moi).