Defragmentation d'un disque sous linux red ha
Fermé
anicetpatrick
Messages postés
41
Date d'inscription
lundi 10 janvier 2005
Statut
Membre
Dernière intervention
2 juin 2007
-
6 sept. 2005 à 14:10
WileCoyote93 - 7 mai 2012 à 10:48
WileCoyote93 - 7 mai 2012 à 10:48
A voir également:
- Defragmentation d'un disque sous linux red ha
- Defragmenter disque dur - Guide
- Cloner disque dur - Guide
- Remplacer disque dur par ssd - Guide
- Nettoyage de disque - Guide
- Linux mint - Télécharger - Systèmes d'exploitation
10 réponses
Salut, il suffit de déplacer les fichiers sur une autre partition et de les replacer sur celle d'origine.
C'est le meilleur défragmenteur qui existe.
PS: La fragmentation sous Linux (ext2, ext3) existe bien mais avec de l'espace libre suffisant (20%) cela ne pause pas de problème. Pour voir la fragmentation d'un fichier exécuter la commande "filefrag <nom du fichier>".
C'est le meilleur défragmenteur qui existe.
PS: La fragmentation sous Linux (ext2, ext3) existe bien mais avec de l'espace libre suffisant (20%) cela ne pause pas de problème. Pour voir la fragmentation d'un fichier exécuter la commande "filefrag <nom du fichier>".
la fragmentation dépand du FS pas du systeme.
un file systeme qui ecrit le fichier dans le premier secteur vide peut etre coupé en 2 (=2 accès disques au niveau systeme en lecture et 4 en ecriture) c'est ça qui ralentit le systeme à force parcequ'en fat quand le disque a eut une longue durée de vie, pratiquement tous les fichiers magnetiquement parlant sont coupés en (jusqu'à 1024 morceaux) autant dire si c'est merdique.
linux utilisant la FAT refait pareil car une fois que le systeme à laché ses ordres au couches de communication materielle là c'est fini c'est le format FAT qui décide comment le fichier est agencé magnétiquement sur le disque et là linux ne peux absoluement plus intervenir.
que ce soit en lecture ou en ecriture.
un file systeme qui ecrit le fichier dans le premier secteur vide peut etre coupé en 2 (=2 accès disques au niveau systeme en lecture et 4 en ecriture) c'est ça qui ralentit le systeme à force parcequ'en fat quand le disque a eut une longue durée de vie, pratiquement tous les fichiers magnetiquement parlant sont coupés en (jusqu'à 1024 morceaux) autant dire si c'est merdique.
linux utilisant la FAT refait pareil car une fois que le systeme à laché ses ordres au couches de communication materielle là c'est fini c'est le format FAT qui décide comment le fichier est agencé magnétiquement sur le disque et là linux ne peux absoluement plus intervenir.
que ce soit en lecture ou en ecriture.
Désolé de vous contredire Roland, c'est le contraire. C'est bel et bien le système d'exploitation qui gère le placement des blocs sur le disque et non une sous-couche FAT.
Pour information, sous Linux, l'entité de base manipulée pour les disques est constituée d'inodes qui sont à la base des systèmes de fichier ext2 et ext3 (les formats 'natifs' de Linux). La FAT est considérée dans le noyau comme un système de fichier avec des inodes 'bricolés' (il suffit de plonger dans les sources du noyau linux pour s'en convaincre). Ceci veut dire que la politique d'écriture et de positionnement des blocs sur le disque est la même pour Linux quelquesoit le système de fichier.
En revanche sous windows, pour optimiser la vitesse en écriture, l'écriture d'un fichier commence à l'endroit où est la tête de lecture, quitte à compléter ailleurs s'il n'ya pas la place d'où la fragmentation.
Pour information, sous Linux, l'entité de base manipulée pour les disques est constituée d'inodes qui sont à la base des systèmes de fichier ext2 et ext3 (les formats 'natifs' de Linux). La FAT est considérée dans le noyau comme un système de fichier avec des inodes 'bricolés' (il suffit de plonger dans les sources du noyau linux pour s'en convaincre). Ceci veut dire que la politique d'écriture et de positionnement des blocs sur le disque est la même pour Linux quelquesoit le système de fichier.
En revanche sous windows, pour optimiser la vitesse en écriture, l'écriture d'un fichier commence à l'endroit où est la tête de lecture, quitte à compléter ailleurs s'il n'ya pas la place d'où la fragmentation.
Désolé de vous contredire Homer_gi... l'algorithme d'allocation est codé séparément pour les différents système de fichiers. Il suffit de se plonger dans le code pour le voir (fonction fat_alloc_clusters spécifique pour la FAT par exemple). Linux peut donc gérer plus ou moins bien la fragmentation de différents systèmes de fichiers....
Mais je suis d'accord sur un point : c'est bien le système d'exploitation qui fait l'allocation.
Cependant, certains systèmes de fichiers ont des caractéristiques qui facilitent une meilleure gestion. Ainsi, avec les systèmes de fichiers usuels sous UNIX (FFS BSD, ext2, reiserfs...), le système de fichier est divisé en groupes de blocks et chaque répertoire est associé à une zone afin 1/ de localiser des fichiers qui sont susceptibles d'être lu ensemble, et 2/ de répartir les espaces libres sur les disques pour favoriser des allocation de fichier pas trop loin lorsqu'un fichier doit être agrandi.
En théorie, rien n'interdit d'implémenter un système de fichier FAT qui considérerait un volume FAT comme divisé en groupe de blocks. Mais comme le principe n'est pas normalisé, cela ne fonctionnerait pas de façon optimal en cas d'échanges entre 2 systèmes : l'implémentation "optimisée" se trouverait pénalisée par le placement de répertoire systèmatiquement dans les premières zones. De plus, je ne pense pas que les développeurs soit forcément motivés pour porter sur le système de fichier FAT, les optimisations Linux... vu l'usage de ce système de fichier, il est préférable de le maintenir simple et fiable.
Mais je suis d'accord sur un point : c'est bien le système d'exploitation qui fait l'allocation.
Cependant, certains systèmes de fichiers ont des caractéristiques qui facilitent une meilleure gestion. Ainsi, avec les systèmes de fichiers usuels sous UNIX (FFS BSD, ext2, reiserfs...), le système de fichier est divisé en groupes de blocks et chaque répertoire est associé à une zone afin 1/ de localiser des fichiers qui sont susceptibles d'être lu ensemble, et 2/ de répartir les espaces libres sur les disques pour favoriser des allocation de fichier pas trop loin lorsqu'un fichier doit être agrandi.
En théorie, rien n'interdit d'implémenter un système de fichier FAT qui considérerait un volume FAT comme divisé en groupe de blocks. Mais comme le principe n'est pas normalisé, cela ne fonctionnerait pas de façon optimal en cas d'échanges entre 2 systèmes : l'implémentation "optimisée" se trouverait pénalisée par le placement de répertoire systèmatiquement dans les premières zones. De plus, je ne pense pas que les développeurs soit forcément motivés pour porter sur le système de fichier FAT, les optimisations Linux... vu l'usage de ce système de fichier, il est préférable de le maintenir simple et fiable.
clarky
Messages postés
60
Date d'inscription
lundi 6 mars 2006
Statut
Membre
Dernière intervention
8 décembre 2006
1
13 sept. 2006 à 10:24
13 sept. 2006 à 10:24
A ce propos, il peut être intéressant de (re)lire le texte de R. Di Cosmo "piège dans le cyberespace" disponible (entre autres) sur http://www.pps.jussieu.fr/~dicosmo/Piege/cybersnare/piege.html
anicetpatrick
Messages postés
41
Date d'inscription
lundi 10 janvier 2005
Statut
Membre
Dernière intervention
2 juin 2007
6 sept. 2005 à 14:53
6 sept. 2005 à 14:53
bsr une fois de plus, quand vous dites que la defragmentation n'existe pas sur les fichiers non-fat, je voudrais vous retourner la question en vous demandant s'il existe une degragmentation en systeme de fichier NTFS(si oui, ce systeme est bel et bien different du fat ),
saga9
Messages postés
5912
Date d'inscription
vendredi 1 avril 2005
Statut
Contributeur
Dernière intervention
17 septembre 2005
876
6 sept. 2005 à 14:58
6 sept. 2005 à 14:58
Ce defaut (la framgentation) n'existe qu'avec windows pas sous linux!!
En effet, la fragmentation est du à une mauvaise gestion de l'organisation des fichiers de la part de windows.
En fait, pour rependre une analogie connue, windows est un peu comme la secraitare qui range mal ses dossiers en mettant à droite et à gauche de l'armoire les elements d'un meme fichier.
Au contraire, Linux range les memes elements d'un fichier les uns à cote des autres.
Resultat, plus on utilise windows on le desordre s'installe (d'ou un certain nombre de pbs: ralentissement, bugs..etc) contrairement à Linux.
la fragmentation n'existe pas sur les systemes de fichiers non-FAT
Là je suis pas vraiment d'accord
Dans la mesure ou l'organisation et la sauvegarde des fichiers sont l'affaire du systeme d'exploitation, un disque dur en FAT devrait ne pas etre fragmenté sous Linux?
Je dis peut etre une betise mais en toute logique, c'est ce que je pense..si quelqu'un connait la reponse, je suis preneur...a verifier donc.
En effet, la fragmentation est du à une mauvaise gestion de l'organisation des fichiers de la part de windows.
En fait, pour rependre une analogie connue, windows est un peu comme la secraitare qui range mal ses dossiers en mettant à droite et à gauche de l'armoire les elements d'un meme fichier.
Au contraire, Linux range les memes elements d'un fichier les uns à cote des autres.
Resultat, plus on utilise windows on le desordre s'installe (d'ou un certain nombre de pbs: ralentissement, bugs..etc) contrairement à Linux.
la fragmentation n'existe pas sur les systemes de fichiers non-FAT
Là je suis pas vraiment d'accord
Dans la mesure ou l'organisation et la sauvegarde des fichiers sont l'affaire du systeme d'exploitation, un disque dur en FAT devrait ne pas etre fragmenté sous Linux?
Je dis peut etre une betise mais en toute logique, c'est ce que je pense..si quelqu'un connait la reponse, je suis preneur...a verifier donc.
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
Je suis désolé mais arrivé à + de 80% de place utilisé dans le disque dur il peut y avoir de la fragmenttation meme si le systéme gére les fichiers pour qu'il n'y en ai pas. Car s'il il n'y à plus d'espace libre contigu pour stocker un fichier (volumineux) ou meme une suite de petit fichier compléte il sera bien oobligé de fragmenté le fichier !
Le systéme à ces limites c'est pour ca d'ailleur qu'il existe bien des defragmenteur sous linux (qui peuvent d'ailleur servir regulierement sur des serveurs).
Le systéme à ces limites c'est pour ca d'ailleur qu'il existe bien des defragmenteur sous linux (qui peuvent d'ailleur servir regulierement sur des serveurs).
Et sinon existe t'il des outils sous linux pour défragmenter mon disque externe en FAT32 ?? J'ai beau l'utiliser sous linux il est à 28% de fragmentation des fichiers...
L'absence de défragmentation manque cruellement...
Vous me direr que je n'ai qu'a changer de FS, mais j'aimerai pouvoir brancher mon disque dur chez des potes qui ont maheureusement windows...
L'absence de défragmentation manque cruellement...
Vous me direr que je n'ai qu'a changer de FS, mais j'aimerai pouvoir brancher mon disque dur chez des potes qui ont maheureusement windows...
On est en plein fantasme...
Le premier fantasme est que la fragmentation, c'est mal... Quelqu'un est-il capable de dire quel est l'impact de la fragmentation des fichiers sur les performances ?
La fragmentation permet au FS d'écrire des fichiers plus gros que le plus gros espace libre contigu, c'est une chance que les FS fragmentent...
Le temps de lecture, cote mal taillée, est le nombre de fragments * le temps d'accès plus la taille totale * le débit... Mais bon, sachant que le temps d'accès est dépendant de l'activité du système qui est multitâche, on doit faire une moyenne...
Pour l'écriture c'est plus compliqué parce que quand on commence à écrire, on ne sait pas quelle sera la taille finale du fichier... Et puis les FS modernes sont journalisés, donc ils peuvent consolider offline.
Les temps d'accès sont de l'ordre des 10ms, les tailles sont très variables, ça veut dire que lire un fichier de 20 fragments est 200ms plus long que lire le même fichier non fragmenté... Pas de quoi casser cinq pattes à un mouton!
A contrario, j'ai jamais vu un Windows gagner sensiblement en performances après défragmentation... Ou alors certains fichiers stratégiques comme la calamiteuse registry.
Enfin on revient souvent à "Linux c'est bien et Windows c'est nul", mais y'a pas d'outil facile pour analyser la fragmentation d'un disque sur Linux.
La grosse différence de performance vient pour moi du fait que le Write-Back cache sous Linux est activé par défaut, et désactivé sous Windows (voir le disque sous gestionnaire de périphérique, propriétés, stratégies). Après, la gestion du temps, de la mémoire virtuelle, des IO bien pourries sous Windows n'en font pas un foudre de guerre c'est clair.
Le premier fantasme est que la fragmentation, c'est mal... Quelqu'un est-il capable de dire quel est l'impact de la fragmentation des fichiers sur les performances ?
La fragmentation permet au FS d'écrire des fichiers plus gros que le plus gros espace libre contigu, c'est une chance que les FS fragmentent...
Le temps de lecture, cote mal taillée, est le nombre de fragments * le temps d'accès plus la taille totale * le débit... Mais bon, sachant que le temps d'accès est dépendant de l'activité du système qui est multitâche, on doit faire une moyenne...
Pour l'écriture c'est plus compliqué parce que quand on commence à écrire, on ne sait pas quelle sera la taille finale du fichier... Et puis les FS modernes sont journalisés, donc ils peuvent consolider offline.
Les temps d'accès sont de l'ordre des 10ms, les tailles sont très variables, ça veut dire que lire un fichier de 20 fragments est 200ms plus long que lire le même fichier non fragmenté... Pas de quoi casser cinq pattes à un mouton!
A contrario, j'ai jamais vu un Windows gagner sensiblement en performances après défragmentation... Ou alors certains fichiers stratégiques comme la calamiteuse registry.
Enfin on revient souvent à "Linux c'est bien et Windows c'est nul", mais y'a pas d'outil facile pour analyser la fragmentation d'un disque sur Linux.
La grosse différence de performance vient pour moi du fait que le Write-Back cache sous Linux est activé par défaut, et désactivé sous Windows (voir le disque sous gestionnaire de périphérique, propriétés, stratégies). Après, la gestion du temps, de la mémoire virtuelle, des IO bien pourries sous Windows n'en font pas un foudre de guerre c'est clair.
