Script pour défragmenter des fichiers en ext4 (ext3 éventuellement)

Hoper · Le 02/04/2012, à 17:05

Bonjour,

Il y a quelques années je m'était un peu battu avec ces histoires de fragmentation sous Linux. J'ignore toujours quand, comment et pourquoi certains fichiers se retrouvent très fragemntés (et pas les autres), mais en tout cas, ça arrive.

Si vous avez remarqué que certains fichiers sont très longs (en lecture), c'est peut etre qu'ils sont très fragmentés. Pour le voir, installez le paquet e2fsprogs. Puis tester la fragmentation du fichier avec :

sudo filefrag /répertoire/fichier

Le nombre de fragment "normal" pour un fichier est extremement variable. Cela dépend du format du FS bien sur (beaucoup plus de fragment en ext3 qu'en ext4), mais aussi des paramètres utilisés lors de la création du FS (nombre d'inodes etc) et bien sur de la taille du fichier. Par expérience, sur de l'ext4, il est tout à fait normal d'avoir entre 2 ou 3 fragment pour chaque Go. Autrement dit, un fichier de 5 Go devrait avoir un nombre de segments compris entre 5 et 15 (environ hein !)

Si ce fichier comporte plus de 50 segments, c'est qu'il est anormalement fragmenté, et que cela peut nuire aux performances.

Que fait ce script ?

Il vérifie le nombre de segment de chacun des fichiers contenu dans le répertoire donné en argument. Puis, si ce nombre dépasse un certain seul (50 par défaut), il recopie le fichier, efface l'ancien, et renomme le nouveau avec l'ancien nom. Ca ne fonctionne pas tout le temps (il faut qu'il reste de la place disponible et contiguë etc) mais en général, ça fonctionne quand même plutôt bien.

ATTENTION : en ext3, les valeurs sont très différentes. Je ferai un post sur le sujet, mais pour le moment je préférai que les "bêta-testeurs" ne l'utilise que sur de l'ext4. Enfin, je vous déconseille de l'utiliser sur autre chose que des fichiers de données "normaux" (et qui ne sont pas en cours d'utilisation).

Le script est téléchargeable ici :
http://hoper.dnsalias.net/tdc/public/vsdefrag
Il faut le rendre exécutable et le lancer avec les droits sudo.

EDIT : Mise à jour en version 1.1, avec l'ajout d'une option de simulation (-s)

Merci d'avance pour les retours

Dernière modification par Hoper (Le 12/04/2012, à 16:35)

JLK · Le 02/04/2012, à 19:14

Salut Hoper.

Merci de t'intéresser à ce problème.
J'ai remarqué que des fichiers de plus de 10 Go sur une partition loin d'être pleine peuvent dépasser la centaines de fragments (même les 120-160 fragments).
Ça se remarque quand tu veux regarder des vidéos en full HD, même si je sais que mon circuit graphique est loin d'être un foudre de guerre.

Je ne comprends pas pourquoi depuis le temps qu'existe ext3 et ext4 qu'il n'y ait pas de défragmentation par défaut quand les ressources du système ne sont pas utilisées par les utilisateurs. Peut-être que ce n'est pas encore au point.

Dernière modification par JLK (Le 02/04/2012, à 19:14)

Hoper · Le 04/04/2012, à 11:08

ATTENTION : Je viens de trouver un gros BUG !

Les droits des fichiers ne sont pas conservés. Pourtant, j'avais bien utilisé l'option -p de cp, mais cela ne suffit pas.
Si vous avez déjà téléchargé le script, vous pouvez le modifier directement.
A la ligne 130, remplacez :

cp -p "$FILE" "$FILE"tmp

par :

cp -a "$FILE" "$FILE"tmp

Nasman · Le 04/04/2012, à 11:14

Pour les quelques personnes qui ont des données sur du ntfs mais qui ont viré Windows, pense tu qu'il soit possible de faire quelque chose pour eux ?

Hoper · Le 04/04/2012, à 11:22

Non. Enfin, il faudrait que je vois comment filefrag réagit sur du ntfs, mais à mon avis pas bien du tout. Je vais déjà devoir me creuser la cervelle sérieusement pour gérer l'ext3... Mais ntfs, non. Vraiment non.

Nasman · Le 04/04/2012, à 11:25

Personnellement je n'ai que du Linux sur mes PC perso mais j'évoquais le cas d'un ancien Windows user qui aurait complêtement remplacé son système Windows par du Linux mais qui n'aurait pas pu transférer ses données ntfs sur de l'ext3 ou 4 (par exemple par manque de place sur le disque et pas de disque annexe).

Hoper · Le 04/04/2012, à 11:27

J'avais bien compris. Personnellement j'ai encore quelques disques en NTFS, et pour différentes raisons. Mais pour pouvoir conserver du NTFS, pas le choix, il faut aussi conserver un windows quelque part, si on veut pouvoir "gérer" ce fs correctement dans le temps (récupération de fichiers, défragmentation, réparation etc).

cep · Le 04/04/2012, à 12:00

:~$ apt-file search ntfsck
ntfs-3g: /bin/ntfsck

ntfsck : Perform consistancy checks on a volume

Hoper · Le 04/04/2012, à 12:15

C'est récent ça.. avant il y avait que ntfsfix qui se contentait de vider le log... Tant mieux si on a maintenant un fsck sous linux, mais personnellement je resterai prudent avec cet outil. (surtout vu le nombre de version de ntfs différentes etc).

JLK · Le 04/04/2012, à 23:00

Pour information, provenant de mon expérience, filefrag avec du NTFS met trois plombes par fichier pour donner le nombre de fragments.

Dernière modification par JLK (Le 04/04/2012, à 23:01)

loran.key · Le 12/04/2012, à 14:34

Testé avec succès.
Je n'ai pas pensé à relever l'espace disque utilisé avant et après usage pour comparer. Dommage.

Une question: as-tu prévu une récursivité dans les répertoires?

Bravo et merci pour la réalisation de ce script!

JLK · Le 12/04/2012, à 14:42

loran.key a écrit :

Testé avec succès.
Je n'ai pas pensé à relever l'espace disque utilisé avant et après usage pour comparer. Dommage.
Une question: as-tu prévu une récursivité dans les répertoires?
Bravo et merci pour la réalisation de ce script!

Tout est bien défragmenté ?

En tout cas, si ce script fonctionne, tu pourrais le proposer aux développeurs du noyau.

Dernière modification par JLK (Le 12/04/2012, à 14:43)

Hoper · Le 12/04/2012, à 14:58

Une question: as-tu prévu une récursivité dans les répertoires?

vsdefrag --help

 Syntaxe : /home/hoper/scripts/vsdefrag [OPTIONS] repertoire

 OPTIONS :
        -h      --help          Affiche la syntaxe
        -g      --gui           Mode graphique (a venir)
        -r      --rec           Mode recursif (repoertoire et sous repertoires)
        -q      --quiet         Aucun affichage
        -v      --verbose       Affiche tous les fichiers
        -m X    --max-extend=X  Fixe le nombre maximal d'extend (Default=50)

Donc oui, récursivité possible avec l'option -r

En tout cas, si ce script fonctionne, tu pourrais le proposer aux développeurs du noyau.

Heu.. oui mais non, ce script ne fait que de la copie de fichier... Ce n'est pas du tout un patch qui pourrait être appliqué aux couches de gestion de l'ext4 hein ! Tu me sur-estime beaucoup la

JLK · Le 12/04/2012, à 15:15

Ça pourrait devenir une commande intégrée.

loran.key · Le 12/04/2012, à 15:38

JLK a écrit :

Tout est bien défragmenté ?

Il est plus sage de dire "tout est moins fragmenté".
Compte tenu de la méthode, il est impossible de garantir que le fichier traité soit d'un seul bloc.
Mais le nombre de fragments diminue considérablement.

Je me pose une question tout de même: l'effacement de "l'ancien" fichier, après avoir été copié, ne créé-t-il pas des espaces vides éparpillés sur le disque? Est-ce que ça ne génère pas une difficulté supplémentaire dans l'agencement des futures données?

JLK · Le 12/04/2012, à 15:46

loran.key a écrit :

JLK a écrit :
Tout est bien défragmenté ?
Il est plus sage de dire "tout est moins fragmenté".
Compte tenu de la méthode, il est impossible de garantir que le fichier traité soit d'un seul bloc.
Mais le nombre de fragments diminue considérablement.

Je me pose une question tout de même: l'effacement de "l'ancien" fichier, après avoir été copié, ne créé-t-il pas des espaces vides éparpillés sur le disque? Est-ce que ça ne génère pas une difficulté supplémentaire dans l'agencement des futures données?

Probablement.
Il me semble que sous Windows, il existe des logiciels de défragmentation qui ont la particularité d'intercepter la copie de fichiers, pour les mettre à un emplacement optimal (c'est-à-dire non fragmenté et si possible vers la périphérie du disque dur, qui est plus rapide).

Hoper · Le 12/04/2012, à 15:56

Je me pose une question tout de même: l'effacement de "l'ancien" fichier, après avoir été copié, ne créé-t-il pas des espaces vides éparpillés sur le disque? Est-ce que ça ne génère pas une difficulté supplémentaire dans l'agencement des futures données?

Tout dépend de la place restante sur ton disque et de la taille des prochains fichiers que tu va écrire dessus
Imaginons que tu avais un gros fichier (plusieurs Go) très fragmenté. (donc des centaines de morceau de quelques Mo par exemple).

L'effacement va rendre disponible tous ces petits espaces de quelques Mo.

Plusieurs cas de figure :

Soit les prochains fichiers que tu écrit sur ce disque sont petits, et ils trouveront alors naturellement leur place dans les "trous" (le FS étant justement assez intelligent pour choisir un espace adapté en fonction de la taille du fichier que tu écrit).

Soit le prochain fichier que tu écrit est de nouveau un gros fichier. La, soit tu as de l'espace libre ailleurs, et ce nouveau gros fichier sera donc écrit ailleurs que dans ces petits trous (c'est l’intérêt d'ext, et c'est pourquoi il fragmente beaucoup moins que windows), soit tu n'a plus du tout de place ailleurs sur le disque, et la effectivement, ton nouveau fichier n'aura pas d'autre choix que de venir combler tous les petits trous. C'est pour cette raison qu'il ne faut jamais trop remplir un système de fichier. A partir de 90%, je considère que le FS est "plein". Au delà de 95%, il devient urgent de rajouter de l'espace, et pas seulement pour éviter un "plantage", mais simplement pour éviter une très grosse diminution des performances à cause d'une apparition massive de fragmentation.

JLK · Le 12/04/2012, à 16:01

Alors comment se fait-il que ext4 fragmente toujours, même avec plusieurs centaines de Go de libre ?

Hoper · Le 12/04/2012, à 16:20

Alors comment se fait-il que ext4 fragmente toujours, même avec plusieurs centaines de Go de libre ?

C'est une question qu'il faudrait poser aux développeurs. Mon avis sur la question (simple hypothèse de ma part) c'est que la fragmentation se produit lorsque le FS ne peut pas connaitre à l'avance la taille final du fichier. Je m'explique. Si tu fais une copie de fichier toute conne de disque à disque avec la commande cp, la, pas de problèmes. La taille final du fichier est connu, donc le système choisira un espace suffisamment grand, et il n'y aura pas de fragmentation.

Par contre, quand tu commence à être dans des situations un peu plus compliqués (par exemple de la copie de fichier en utilisant des protocoles réseaux merdiques genre cifs et compagnie...) et bien la, je ne suis pas du tout certain que l'OS puisse connaitre la taille du fichier à l'avance. Peut etre... mais peut être pas. Et si il peut pas la connaitre, et bien il n'a pas d'autre solution que d'y aller au hasard, en allouant un premier bloc d'une taille "moyenne" et d'en ajouter au fur et à mesure de la copie.

Il y a surement d'autres raisons, mais je pense que celle la en est une, et une "bonne".

Dernière modification par Hoper (Le 12/04/2012, à 16:20)

Hoper · Le 12/04/2012, à 16:37

Je viens de mettre en ligne une version 1.1 du script. L'ajout est minime, mais il rassurera peut etre les testeurs J'ai ajouté une option "-s" (simulation) qui permet de lancer le script sans que rien ne soit réellement effectué (les fichiers de l'utilisateur ne sont donc pas du tout modifiés)

Pour voir si vos fichiers sont fragmentés ou pas, il suffit de lancer le script en mode simulation et en mode verbeux :

sudo ./vsdefrag -vs /répertoire

Prochaine étape, la version 2 en mode graphique avec zenity.

Dernière modification par Hoper (Le 12/04/2012, à 16:38)

JLK · Le 12/04/2012, à 16:54

Hoper a écrit :

Alors comment se fait-il que ext4 fragmente toujours, même avec plusieurs centaines de Go de libre ?
C'est une question qu'il faudrait poser aux développeurs. Mon avis sur la question (simple hypothèse de ma part) c'est que la fragmentation se produit lorsque le FS ne peut pas connaitre à l'avance la taille final du fichier. Je m'explique. Si tu fais une copie de fichier toute conne de disque à disque avec la commande cp, la, pas de problèmes. La taille final du fichier est connu, donc le système choisira un espace suffisamment grand, et il n'y aura pas de fragmentation.
Par contre, quand tu commence à être dans des situations un peu plus compliqués (par exemple de la copie de fichier en utilisant des protocoles réseaux merdiques genre cifs et compagnie...) et bien la, je ne suis pas du tout certain que l'OS puisse connaitre la taille du fichier à l'avance. Peut etre... mais peut être pas. Et si il peut pas la connaitre, et bien il n'a pas d'autre solution que d'y aller au hasard, en allouant un premier bloc d'une taille "moyenne" et d'en ajouter au fur et à mesure de la copie.
Il y a surement d'autres raisons, mais je pense que celle la en est une, et une "bonne".

J'en suis arrivé à la même déduction que toi. Sauf qu'il y a toujours fragmentation, avec ou sans connaissance de la taille des fichiers.

Hoper · Le 12/04/2012, à 23:39

J'en suis arrivé à la même déduction que toi. Sauf qu'il y a toujours fragmentation, avec ou sans connaissance de la taille des fichiers

Après tout dépend de ce qu'on appel fragmentation... Tant que ca reste léger, ce n'est absolument pas gênant. (N'oublions pas qu'il y a sûrement d'autres considérations à prendre en compte... Groupement d'écriture diverses en une seule opération pour gagner en perf etc).

JLK · Le 13/04/2012, à 00:38

Très certainement.

HLFH · Le 13/04/2012, à 17:47

Si vous connaissez un logiciel de défrag sous Linux pour le NTFS, ce serait super cool merci

doupdoup · Le 23/04/2012, à 21:58

Merci pour ce script efficace.
Je l’exécute sur un RAID 5 en ext4 de 4 Tio, avec des fichiers allant de quelque Kio jusqu’à 300 Gio (faut pas être pressé la première fois)

Pour ma part je l'ai un peu modifié en reprenant le script de cp_p afin d'avoir une barre de progression lors de la recopie du fichier fragmenté.

A la place de:

cp -a "$FILE" "$FILE"tmp

J'ai mis:

            echo
            echo "Recopie du fichier '$FILE':"
            {
                set -e
                strace -q -ewrite cp -a -- "$FILE" "$FILE"tmp 2>&1 \
                | awk '{
                count += $NF
                if (count % 10 == 0) {
                percent = count / total_size * 100
                printf "%3d%% [", percent
                for (i=0;i<=percent;i++)
                printf "="
                printf ">"
                for (i=percent;i<100;i++)
                printf " "
                printf "]\r"
                    }
                }
                END { print "" }' total_size=$(stat -c '%s' "$FILE") count=0
            }

Ce qui donne par exemple:

/media/tempfrag/fichie32 ok (1 extends)
/media/tempfrag/fichie09 semble tres fragmente (87 extends)

Recopie du fichier '/media/tempfrag/fichie09':
 99% [====================================================================================================> ]
resultat apres recopie : 113 extents

/media/tempfrag/fichie18 ok (11 extends)
/media/tempfrag/fichie11 semble tres fragmente (148 extends)

Recopie du fichier '/media/tempfrag/fichie11':
 99% [====================================================================================================> ]
resultat apres recopie : 132 extents

/media/tempfrag/fichie33 ok (1 extends)
/media/tempfrag/fichie22 ok (1 extends)
/media/tempfrag/fichie13 ok (1 extends)
/media/tempfrag/fichie68 ok (1 extends)

Par contre, vue que l'ext4 se défragmente a l’usage il ne faut pas hésiter à exécuter le script plusieurs fois.

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 02/04/2012, à 17:05

Script pour défragmenter des fichiers en ext4 (ext3 éventuellement)

#2 Le 02/04/2012, à 19:14

Re : Script pour défragmenter des fichiers en ext4 (ext3 éventuellement)

#3 Le 04/04/2012, à 11:08

Re : Script pour défragmenter des fichiers en ext4 (ext3 éventuellement)

#4 Le 04/04/2012, à 11:14

Re : Script pour défragmenter des fichiers en ext4 (ext3 éventuellement)

#5 Le 04/04/2012, à 11:22

Re : Script pour défragmenter des fichiers en ext4 (ext3 éventuellement)

#6 Le 04/04/2012, à 11:25

Re : Script pour défragmenter des fichiers en ext4 (ext3 éventuellement)

#7 Le 04/04/2012, à 11:27

Re : Script pour défragmenter des fichiers en ext4 (ext3 éventuellement)

#8 Le 04/04/2012, à 12:00

Re : Script pour défragmenter des fichiers en ext4 (ext3 éventuellement)

#9 Le 04/04/2012, à 12:15

Re : Script pour défragmenter des fichiers en ext4 (ext3 éventuellement)

#10 Le 04/04/2012, à 23:00

Re : Script pour défragmenter des fichiers en ext4 (ext3 éventuellement)

#11 Le 12/04/2012, à 14:34

Re : Script pour défragmenter des fichiers en ext4 (ext3 éventuellement)

#12 Le 12/04/2012, à 14:42

Re : Script pour défragmenter des fichiers en ext4 (ext3 éventuellement)

#13 Le 12/04/2012, à 14:58

Re : Script pour défragmenter des fichiers en ext4 (ext3 éventuellement)

#14 Le 12/04/2012, à 15:15

Re : Script pour défragmenter des fichiers en ext4 (ext3 éventuellement)

#15 Le 12/04/2012, à 15:38

Re : Script pour défragmenter des fichiers en ext4 (ext3 éventuellement)

#16 Le 12/04/2012, à 15:46

Re : Script pour défragmenter des fichiers en ext4 (ext3 éventuellement)

#17 Le 12/04/2012, à 15:56

Re : Script pour défragmenter des fichiers en ext4 (ext3 éventuellement)

#18 Le 12/04/2012, à 16:01

Re : Script pour défragmenter des fichiers en ext4 (ext3 éventuellement)

#19 Le 12/04/2012, à 16:20

Re : Script pour défragmenter des fichiers en ext4 (ext3 éventuellement)

#20 Le 12/04/2012, à 16:37

Re : Script pour défragmenter des fichiers en ext4 (ext3 éventuellement)

#21 Le 12/04/2012, à 16:54

Re : Script pour défragmenter des fichiers en ext4 (ext3 éventuellement)

#22 Le 12/04/2012, à 23:39

Re : Script pour défragmenter des fichiers en ext4 (ext3 éventuellement)

#23 Le 13/04/2012, à 00:38

Re : Script pour défragmenter des fichiers en ext4 (ext3 éventuellement)

#24 Le 13/04/2012, à 17:47

Re : Script pour défragmenter des fichiers en ext4 (ext3 éventuellement)

#25 Le 23/04/2012, à 21:58

Re : Script pour défragmenter des fichiers en ext4 (ext3 éventuellement)

Pied de page des forums