Cette opération indispensable pour l'utilisateur avertis (Enfin, celui
qui veut que son ordinateur fonctionne plus vite sans défragmenter vu
qu'il n'y pas de défragmenteur sous Linux...) qui souhaite "optimiser"
sa viellie brèle peut être maintenant effectuée en 60 secondes...
Maljeureusement, il faut un processeur super costaud !
(On se demande pourquoi alors recomplier son noyau, mais bon, on n'en
est pas à une contradiction près avec Linux....)
Recomplier son noyau notamment à enlever des choses "très
consommatrice", comme le suport de la dsiquette 720 Ko et 1.44 MB, ou
encore optimiser sa distros pour son PIII
Bref, si vous ne savez pas faire cette opération, vous êtes un crétin
et faut rester sous WIndows
Faudrait d'abord nous prouver en quoi la fragmentation est un souci...
[...]
Pour ne pas subir ce genre de dégradation, il faut éviter / limiter / réduire la fragmentation.
Et ça, ça dépend du FS et surtout de son implémentation dans l'OS.
Surtout de son implémentation. C'est bon de lire cette évidence au lieu des habituelles absurdités du genre "FAT ça fragmente, extN ça ne fragmente pas". Un système de fichiers sur disque n'est qu'une structure, c'est la façon dont on s'en sert qui compte. Qu'est-ce qui empêche d'écrire un gestionnaire de FAT qui fragmente peu et un gestionnaire d'extN qui fragmente beaucoup ?
D'autre part, AMA il faut relativiser l'impact de la fragmentation, surtout des gros fichiers. Sur un disque avec un débit séquentiel de 100 Mo/s et un temps d'accès moyen de 10 ms, la présence d'un fragment équivaut à 1 Mo (100 Mo/s * 10 ms) supplémentaire. Sur un fichier de 100 ko, c'est énorme. Sur un fichier de 10 Mo, c'est modeste. Je trouve que les indices de fragmentation habituellement affichés par les outils de gestion de systèmes de fichiers, en pourcentage ou nombre de fichiers fragmentés, ne sont pas très pertinents ; AMA par exemple il serait plus judicieux d'exprimer la fragmentation en pourcentage du nombre de fragments par rapport au nombre de blocs alloués, 0% indiquant l'absence de fragmentation et 100% la fragmentation maximale, c'est-à-dire quand aucun bloc n'est contigu.
Merci pour ces précisions. Pour ta dernière remarque il me semble de Windows donne cette valeur sous le forme du "Nombre moyen de fragments par fichiers".
Par exemple 1,08 sur une machine que je viens de tester, donc un peu moins de 10%
Le 17/12/2011 12:16, Pascal Hambourg a écrit :
Salut,
Ascadix a écrit :
Tonton Th a pensé très fort :
Faudrait d'abord nous prouver en quoi la fragmentation est
un souci...
[...]
Pour ne pas subir ce genre de dégradation, il faut éviter / limiter /
réduire la fragmentation.
Et ça, ça dépend du FS et surtout de son implémentation dans l'OS.
Surtout de son implémentation. C'est bon de lire cette évidence au lieu
des habituelles absurdités du genre "FAT ça fragmente, extN ça ne
fragmente pas". Un système de fichiers sur disque n'est qu'une
structure, c'est la façon dont on s'en sert qui compte. Qu'est-ce qui
empêche d'écrire un gestionnaire de FAT qui fragmente peu et un
gestionnaire d'extN qui fragmente beaucoup ?
D'autre part, AMA il faut relativiser l'impact de la fragmentation,
surtout des gros fichiers. Sur un disque avec un débit séquentiel de 100
Mo/s et un temps d'accès moyen de 10 ms, la présence d'un fragment
équivaut à 1 Mo (100 Mo/s * 10 ms) supplémentaire. Sur un fichier de 100
ko, c'est énorme. Sur un fichier de 10 Mo, c'est modeste. Je trouve que
les indices de fragmentation habituellement affichés par les outils de
gestion de systèmes de fichiers, en pourcentage ou nombre de fichiers
fragmentés, ne sont pas très pertinents ; AMA par exemple il serait plus
judicieux d'exprimer la fragmentation en pourcentage du nombre de
fragments par rapport au nombre de blocs alloués, 0% indiquant l'absence
de fragmentation et 100% la fragmentation maximale, c'est-à-dire quand
aucun bloc n'est contigu.
Merci pour ces précisions. Pour ta dernière remarque il me semble de
Windows donne cette valeur sous le forme du "Nombre moyen de fragments
par fichiers".
Par exemple 1,08 sur une machine que je viens de tester, donc un peu
moins de 10%
Faudrait d'abord nous prouver en quoi la fragmentation est un souci...
[...]
Pour ne pas subir ce genre de dégradation, il faut éviter / limiter / réduire la fragmentation.
Et ça, ça dépend du FS et surtout de son implémentation dans l'OS.
Surtout de son implémentation. C'est bon de lire cette évidence au lieu des habituelles absurdités du genre "FAT ça fragmente, extN ça ne fragmente pas". Un système de fichiers sur disque n'est qu'une structure, c'est la façon dont on s'en sert qui compte. Qu'est-ce qui empêche d'écrire un gestionnaire de FAT qui fragmente peu et un gestionnaire d'extN qui fragmente beaucoup ?
D'autre part, AMA il faut relativiser l'impact de la fragmentation, surtout des gros fichiers. Sur un disque avec un débit séquentiel de 100 Mo/s et un temps d'accès moyen de 10 ms, la présence d'un fragment équivaut à 1 Mo (100 Mo/s * 10 ms) supplémentaire. Sur un fichier de 100 ko, c'est énorme. Sur un fichier de 10 Mo, c'est modeste. Je trouve que les indices de fragmentation habituellement affichés par les outils de gestion de systèmes de fichiers, en pourcentage ou nombre de fichiers fragmentés, ne sont pas très pertinents ; AMA par exemple il serait plus judicieux d'exprimer la fragmentation en pourcentage du nombre de fragments par rapport au nombre de blocs alloués, 0% indiquant l'absence de fragmentation et 100% la fragmentation maximale, c'est-à-dire quand aucun bloc n'est contigu.
Merci pour ces précisions. Pour ta dernière remarque il me semble de Windows donne cette valeur sous le forme du "Nombre moyen de fragments par fichiers".
Par exemple 1,08 sur une machine que je viens de tester, donc un peu moins de 10%
Nicolas George
Pascal Hambourg , dans le message <jchtn7$10fm$, a écrit :
fragmente pas". Un système de fichiers sur disque n'est qu'une structure, c'est la façon dont on s'en sert qui compte.
Oui, mais pas complètement : la fragmentation arrive si on utilise un algorithme naïf d'allocation, utiliser un algorithme plus intelligent nécessite probablement de maintenir des données plus détaillées à jour. Si ces données ne sont pas stockées dans les structures du filesystem, il faut les reconstruire entièrement au montage, ce qui est parfois rédhibitoire.
Pascal Hambourg , dans le message <jchtn7$10fm$1@saria.nerim.net>, a
écrit :
fragmente pas". Un système de fichiers sur disque n'est qu'une
structure, c'est la façon dont on s'en sert qui compte.
Oui, mais pas complètement : la fragmentation arrive si on utilise un
algorithme naïf d'allocation, utiliser un algorithme plus intelligent
nécessite probablement de maintenir des données plus détaillées à jour. Si
ces données ne sont pas stockées dans les structures du filesystem, il faut
les reconstruire entièrement au montage, ce qui est parfois rédhibitoire.
Pascal Hambourg , dans le message <jchtn7$10fm$, a écrit :
fragmente pas". Un système de fichiers sur disque n'est qu'une structure, c'est la façon dont on s'en sert qui compte.
Oui, mais pas complètement : la fragmentation arrive si on utilise un algorithme naïf d'allocation, utiliser un algorithme plus intelligent nécessite probablement de maintenir des données plus détaillées à jour. Si ces données ne sont pas stockées dans les structures du filesystem, il faut les reconstruire entièrement au montage, ce qui est parfois rédhibitoire.
Pascal Hambourg
Ascadix a écrit :
Yliur avait prétendu :
Ascadix a écrit :
Que la tête saute d'une piste du début à une piste de fin, ou s'arréte par une piste intermédiaire pour lire qq secteurs, c'est pas la même vitesse.
Des références ? Ce n'est pas un moteur précis, du genre pas-à-pas ?
Non, pas du tout. Ce n'est pas un moteur rotatif. L'actionneur du bras porte-tête ressemble plutôt à une bobine qui se déplace dans le champ magnétique d'un aimant permanent. On doit trouver des photos assez facilement.
Mais pour résumer, même si le moteur du bras est précis, il faut quand même prendre en compte que pour accéder à des secteurs dispersés, il faut que le disque fasse les manips suivantes: - déplacer la tête vers la piste souhaitée (et suivant qu'elleest proche ou loin, ça prend pas autant de temps) - se caller / vérifier le bon alignement de la tête sur la piste (sur les informations de formatage bas-niveau)
C'est le "seek time", qui n'est pas proportionnel à la distance entre les pistes de départ et d'arrivée. Ordre de grandeur : 1 ms entre deux pistes consécutives, 20 ms entre le début et la fin du disque, avec une moyenne de 10 ms entre deux pistes quelconques.
- repérer les marques de début/fin de secteurs - attendre que le/les secteurs à lire arrivent sous tête (dépend de la vitesse derotation des plateaux)
C'est le "latency time", en moyenne un demi-tour de rotation, soit 4,2 ms à 7200 tours/minute.
Ascadix a écrit :
Yliur avait prétendu :
Ascadix <ascadix.ng@free.fr> a écrit :
Que la tête saute d'une piste du début à une piste de fin, ou
s'arréte par une piste intermédiaire pour lire qq secteurs, c'est pas
la même vitesse.
Des références ? Ce n'est pas un moteur précis, du genre pas-à-pas ?
Non, pas du tout. Ce n'est pas un moteur rotatif. L'actionneur du bras
porte-tête ressemble plutôt à une bobine qui se déplace dans le champ
magnétique d'un aimant permanent. On doit trouver des photos assez
facilement.
Mais pour résumer, même si le moteur du bras est précis, il faut quand
même prendre en compte que pour accéder à des secteurs dispersés, il
faut que le disque fasse les manips suivantes:
- déplacer la tête vers la piste souhaitée (et suivant qu'elleest
proche ou loin, ça prend pas autant de temps)
- se caller / vérifier le bon alignement de la tête sur la piste (sur
les informations de formatage bas-niveau)
C'est le "seek time", qui n'est pas proportionnel à la distance entre
les pistes de départ et d'arrivée. Ordre de grandeur : 1 ms entre deux
pistes consécutives, 20 ms entre le début et la fin du disque, avec une
moyenne de 10 ms entre deux pistes quelconques.
- repérer les marques de début/fin de secteurs
- attendre que le/les secteurs à lire arrivent sous tête (dépend de la
vitesse derotation des plateaux)
C'est le "latency time", en moyenne un demi-tour de rotation, soit 4,2
ms à 7200 tours/minute.
Que la tête saute d'une piste du début à une piste de fin, ou s'arréte par une piste intermédiaire pour lire qq secteurs, c'est pas la même vitesse.
Des références ? Ce n'est pas un moteur précis, du genre pas-à-pas ?
Non, pas du tout. Ce n'est pas un moteur rotatif. L'actionneur du bras porte-tête ressemble plutôt à une bobine qui se déplace dans le champ magnétique d'un aimant permanent. On doit trouver des photos assez facilement.
Mais pour résumer, même si le moteur du bras est précis, il faut quand même prendre en compte que pour accéder à des secteurs dispersés, il faut que le disque fasse les manips suivantes: - déplacer la tête vers la piste souhaitée (et suivant qu'elleest proche ou loin, ça prend pas autant de temps) - se caller / vérifier le bon alignement de la tête sur la piste (sur les informations de formatage bas-niveau)
C'est le "seek time", qui n'est pas proportionnel à la distance entre les pistes de départ et d'arrivée. Ordre de grandeur : 1 ms entre deux pistes consécutives, 20 ms entre le début et la fin du disque, avec une moyenne de 10 ms entre deux pistes quelconques.
- repérer les marques de début/fin de secteurs - attendre que le/les secteurs à lire arrivent sous tête (dépend de la vitesse derotation des plateaux)
C'est le "latency time", en moyenne un demi-tour de rotation, soit 4,2 ms à 7200 tours/minute.
Pascal Hambourg
Nicolas George a écrit :
Oui, mais pas complètement : la fragmentation arrive si on utilise un algorithme naïf d'allocation, utiliser un algorithme plus intelligent nécessite probablement de maintenir des données plus détaillées à jour. Si ces données ne sont pas stockées dans les structures du filesystem, il faut les reconstruire entièrement au montage, ce qui est parfois rédhibitoire.
Quel genre de données plus détaillées ?
Nicolas George a écrit :
Oui, mais pas complètement : la fragmentation arrive si on utilise un
algorithme naïf d'allocation, utiliser un algorithme plus intelligent
nécessite probablement de maintenir des données plus détaillées à jour. Si
ces données ne sont pas stockées dans les structures du filesystem, il faut
les reconstruire entièrement au montage, ce qui est parfois rédhibitoire.
Oui, mais pas complètement : la fragmentation arrive si on utilise un algorithme naïf d'allocation, utiliser un algorithme plus intelligent nécessite probablement de maintenir des données plus détaillées à jour. Si ces données ne sont pas stockées dans les structures du filesystem, il faut les reconstruire entièrement au montage, ce qui est parfois rédhibitoire.
Quel genre de données plus détaillées ?
Pascal Hambourg
denis.paris a écrit :
Le 17/12/2011 12:16, Pascal Hambourg a écrit :
Je trouve que les indices de fragmentation habituellement affichés par les outils de gestion de systèmes de fichiers, en pourcentage ou nombre de fichiers fragmentés, ne sont pas très pertinents ; AMA par exemple il serait plus judicieux d'exprimer la fragmentation en pourcentage du nombre de fragments par rapport au nombre de blocs alloués, 0% indiquant l'absence de fragmentation et 100% la fragmentation maximale, c'est-à-dire quand aucun bloc n'est contigu.
Merci pour ces précisions. Pour ta dernière remarque il me semble de Windows donne cette valeur sous le forme du "Nombre moyen de fragments par fichiers".
Cela ne me satisfait pas vraiment, car cela ne tient pas compte de la taille des fichiers. Trois fragments dans un fichier de 10 Mo, c'est beaucoup moins pénalisant que dans un fichier de 10 ko.
denis.paris a écrit :
Le 17/12/2011 12:16, Pascal Hambourg a écrit :
Je trouve que
les indices de fragmentation habituellement affichés par les outils de
gestion de systèmes de fichiers, en pourcentage ou nombre de fichiers
fragmentés, ne sont pas très pertinents ; AMA par exemple il serait plus
judicieux d'exprimer la fragmentation en pourcentage du nombre de
fragments par rapport au nombre de blocs alloués, 0% indiquant l'absence
de fragmentation et 100% la fragmentation maximale, c'est-à-dire quand
aucun bloc n'est contigu.
Merci pour ces précisions. Pour ta dernière remarque il me semble de
Windows donne cette valeur sous le forme du "Nombre moyen de fragments
par fichiers".
Cela ne me satisfait pas vraiment, car cela ne tient pas compte de la
taille des fichiers. Trois fragments dans un fichier de 10 Mo, c'est
beaucoup moins pénalisant que dans un fichier de 10 ko.
Je trouve que les indices de fragmentation habituellement affichés par les outils de gestion de systèmes de fichiers, en pourcentage ou nombre de fichiers fragmentés, ne sont pas très pertinents ; AMA par exemple il serait plus judicieux d'exprimer la fragmentation en pourcentage du nombre de fragments par rapport au nombre de blocs alloués, 0% indiquant l'absence de fragmentation et 100% la fragmentation maximale, c'est-à-dire quand aucun bloc n'est contigu.
Merci pour ces précisions. Pour ta dernière remarque il me semble de Windows donne cette valeur sous le forme du "Nombre moyen de fragments par fichiers".
Cela ne me satisfait pas vraiment, car cela ne tient pas compte de la taille des fichiers. Trois fragments dans un fichier de 10 Mo, c'est beaucoup moins pénalisant que dans un fichier de 10 ko.
denis.paris
Le 17/12/2011 12:44, Pascal Hambourg a écrit :
denis.paris a écrit :
Le 17/12/2011 12:16, Pascal Hambourg a écrit :
Je trouve que les indices de fragmentation habituellement affichés par les outils de gestion de systèmes de fichiers, en pourcentage ou nombre de fichiers fragmentés, ne sont pas très pertinents ; AMA par exemple il serait plus judicieux d'exprimer la fragmentation en pourcentage du nombre de fragments par rapport au nombre de blocs alloués, 0% indiquant l'absence de fragmentation et 100% la fragmentation maximale, c'est-à-dire quand aucun bloc n'est contigu.
Merci pour ces précisions. Pour ta dernière remarque il me semble de Windows donne cette valeur sous le forme du "Nombre moyen de fragments par fichiers".
Cela ne me satisfait pas vraiment, car cela ne tient pas compte de la taille des fichiers. Trois fragments dans un fichier de 10 Mo, c'est beaucoup moins pénalisant que dans un fichier de 10 ko.
OK, on peut cependant trier le rapport par taille et repérer les fichiers les plus critiques, il ne sont pas forcément très nombreux.
En effet dans mon cas, Windows à réussi la performance de fragmenter un fichier de 36 Ko (ntuser.dat.log) en 318 fragments... Sachant qu'un cluster fait 512 octets, ils sont quand même très forts chez Microsoft!
Comme ce fichier est verrouillé il est difficile à défragmenter. Il se peut que ce soit cela qui fasse ramer cette machine de temps en temps.
Le 17/12/2011 12:44, Pascal Hambourg a écrit :
denis.paris a écrit :
Le 17/12/2011 12:16, Pascal Hambourg a écrit :
Je trouve que
les indices de fragmentation habituellement affichés par les outils de
gestion de systèmes de fichiers, en pourcentage ou nombre de fichiers
fragmentés, ne sont pas très pertinents ; AMA par exemple il serait plus
judicieux d'exprimer la fragmentation en pourcentage du nombre de
fragments par rapport au nombre de blocs alloués, 0% indiquant l'absence
de fragmentation et 100% la fragmentation maximale, c'est-à-dire quand
aucun bloc n'est contigu.
Merci pour ces précisions. Pour ta dernière remarque il me semble de
Windows donne cette valeur sous le forme du "Nombre moyen de fragments
par fichiers".
Cela ne me satisfait pas vraiment, car cela ne tient pas compte de la
taille des fichiers. Trois fragments dans un fichier de 10 Mo, c'est
beaucoup moins pénalisant que dans un fichier de 10 ko.
OK, on peut cependant trier le rapport par taille et repérer les
fichiers les plus critiques, il ne sont pas forcément très nombreux.
En effet dans mon cas, Windows à réussi la performance de fragmenter un
fichier de 36 Ko (ntuser.dat.log) en 318 fragments... Sachant qu'un
cluster fait 512 octets, ils sont quand même très forts chez Microsoft!
Comme ce fichier est verrouillé il est difficile à défragmenter. Il se
peut que ce soit cela qui fasse ramer cette machine de temps en temps.
Je trouve que les indices de fragmentation habituellement affichés par les outils de gestion de systèmes de fichiers, en pourcentage ou nombre de fichiers fragmentés, ne sont pas très pertinents ; AMA par exemple il serait plus judicieux d'exprimer la fragmentation en pourcentage du nombre de fragments par rapport au nombre de blocs alloués, 0% indiquant l'absence de fragmentation et 100% la fragmentation maximale, c'est-à-dire quand aucun bloc n'est contigu.
Merci pour ces précisions. Pour ta dernière remarque il me semble de Windows donne cette valeur sous le forme du "Nombre moyen de fragments par fichiers".
Cela ne me satisfait pas vraiment, car cela ne tient pas compte de la taille des fichiers. Trois fragments dans un fichier de 10 Mo, c'est beaucoup moins pénalisant que dans un fichier de 10 ko.
OK, on peut cependant trier le rapport par taille et repérer les fichiers les plus critiques, il ne sont pas forcément très nombreux.
En effet dans mon cas, Windows à réussi la performance de fragmenter un fichier de 36 Ko (ntuser.dat.log) en 318 fragments... Sachant qu'un cluster fait 512 octets, ils sont quand même très forts chez Microsoft!
Comme ce fichier est verrouillé il est difficile à défragmenter. Il se peut que ce soit cela qui fasse ramer cette machine de temps en temps.
