je viens de faire (comme tous les mois) la defrag de mes deux machines
Windows.
pour la pire, (la mienne) ca donne ca:
Partition C: Windows (139.638 files pour environ 37 GB utilisés)
Defraggler:
-------------------------------------
Avant la defrag:
1838 Fragmented Files
7.899 Total Fragments
16% Fragmentation
Après la defrag:
8 Fragmented Files
36 Total Fragments
12% Fragmentation
------------------------------------
Comme ca au premier coup d'oeil: avant 16% , après 12%.
Pas terrible...
A y regarder de plus près: d'ou viennent ces pourcentages?
En gros
- avant ~140 000 fichiers, dont 8 000 sont fragmentés. (ca fait pas 16%
ca ???)
- après ~140 000 fichiers, dont 36 sont fragmentés. (ca fait pas 12% ca
???)
Si je compare maintenant a OSX (snow-leopard) dont je me sers plutot
rarement et qui a beaucoup moins de logiciels et que j'ai testé il y a
quelques jours:
Partition OSX
hfsdebug-lite -s
-------------------------------------
# Volume Summary Information
files = 346206
folders = 89708
aliases = 1
hard links = 1830
symbolic links = 10708
invisible files = 54
empty files = 2463
# Data Forks
non-zero data forks = 343573
fragmented data forks = 23864
allocation blocks used = 5486045
allocated storage = 22470840320 bytes
(21944180.00 KB/21429.86 MB/20.93 GB)
actual usage = 21565315056 bytes
(21059877.98 KB/20566.29 MB/20.08 GB)
total extent records = 343591
total extent descriptors = 344217
overflow extent records = 18
------------------------------------
1re constation: le nombre total de fichiers d'OSX (hors fragmentation)
est plus du double (~345 000) pour seulement 21 GB utilisés.
2e constatation: le nombre de fragments OSX est 3 fois plus elevé (~24
000) que mon Windows non-défragmenté.
3e constatation: une vraie defrag sort al a fin: 8 fichiers non
fragmentés avec 36 fragments au total, comme ca, les doigts dans le nez,
sans reboot.
4e constation: la defrag on s'en fout quand on a un SSD. (mais j'en ai pas).
5e constatation: quand on a un SSD, la défrag automatique d'OSX réduit
inutilement la durée de vie de la mémoire: vaut mieux pas avoir de
défrag du tout sur le SSD.
Ne pas oublier d'installer TRIM enabler si vous z'avez un SSD pas d'Apple.
http://osxdaily.com/2012/01/03/enable-trim-all-ssd-mac-os-x-lion/
Mes conclusions
- OSX est déja d'avantage "fragmenté" que Windows (en nombre de fichiers)
- Il fragmente peut être naturellement peu, mais rien ne vaut une
_vraie_ défrag chaque mois.
- Apple vous le dit pas, mais bouzille joyeusement vos SSD rajoutés.
--
One computer and three operating systems, not the other way round.
One wife and many hotels, not the other way round ! ;-)
Seulement lorsqu'un fichier EXT3 ou EXT4 est ecrit "là où il y aura la place de le faire" et qu'il grandit après, on fait quoi?
Il se fragmente. À titre indicatif, j'ai 5% de fichiers fragmentés au bout de presque trois ans (en EXT3).
En fait le problème avec Linux esr résolu différement. Persque personne ne garde une distro aussi longtemps. ;-)
Foutaise.
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
Alf92
"£g" <l.g> a écrit
La raison de la défragmentation est la force centrifuge due à la rotation du DD, plus de 7000 tours, avec cette force dite << skating >> pousse les données vers l'extérieure un peu n'importe où, la défragmentation les ramènes au centre.
Et si vous ne croyez pas celle-la, je peux toujours réfléchir à une autre, plus * énorme *.
il y a un paramètre important que tu oublies dans le processus de fragmentation : la chaleur. plus le disque est froid, plus les données se rapprochent (pour se tenir chaud). d'où l'intérêt d'une bonne ventilation des DD.
"£g" <l.g> a écrit
La raison de la défragmentation est la force centrifuge due à la rotation du
DD, plus de 7000 tours, avec cette force dite << skating >> pousse les données
vers l'extérieure un peu n'importe où, la défragmentation les ramènes au
centre.
Et si vous ne croyez pas celle-la, je peux toujours réfléchir à une autre,
plus * énorme *.
il y a un paramètre important que tu oublies dans le processus de fragmentation
: la chaleur.
plus le disque est froid, plus les données se rapprochent (pour se tenir chaud).
d'où l'intérêt d'une bonne ventilation des DD.
La raison de la défragmentation est la force centrifuge due à la rotation du DD, plus de 7000 tours, avec cette force dite << skating >> pousse les données vers l'extérieure un peu n'importe où, la défragmentation les ramènes au centre.
Et si vous ne croyez pas celle-la, je peux toujours réfléchir à une autre, plus * énorme *.
il y a un paramètre important que tu oublies dans le processus de fragmentation : la chaleur. plus le disque est froid, plus les données se rapprochent (pour se tenir chaud). d'où l'intérêt d'une bonne ventilation des DD.
Alf92
"Laszlo Lebrun" a écrit
le SSD est vraiment la solution...
pas vraiment ppour un pagefile. A ce prix il vaut mieux de la RAM.
oui sauf que la tendance va vers la mémoire soudée et non extensible. (voir netbook Asus)
"Laszlo Lebrun" <lazlo_lebrun@laszlomail.com> a écrit
le SSD est vraiment la solution...
pas vraiment ppour un pagefile. A ce prix il vaut mieux de la RAM.
oui sauf que la tendance va vers la mémoire soudée et non extensible.
(voir netbook Asus)
pas vraiment ppour un pagefile. A ce prix il vaut mieux de la RAM.
oui sauf que la tendance va vers la mémoire soudée et non extensible. (voir netbook Asus)
Laszlo Lebrun
On 27.10.2012 13:29, François wrote:
Le 27/10/2012 13:11, Stephane Legras-Decussy a écrit :
c'est pas du tout ma spécialité l'info système mais j'ai toujours été dubitatif devant le remplissage de trou sans fragmenter ...
Le système recherche un trou de taille suffisante pour accueillir le fichier en entier, au lieu de le découper en petits morceaux pour remplir plusieurs petits trous. Il ne sera découpé que s'il ne reste pas de trou assez grand, c'est à dire quand la partition approche de la saturation.
non, bien avant. Il y aura beaucoup plus de trous, plus petits ...
En plus c'est idiot. Découper un VOB de 2 GO en 5 fragments n'a jamais ralenti personne.
-- One computer and three operating systems, not the other way round. One wife and many hotels, not the other way round ! ;-)
On 27.10.2012 13:29, François wrote:
Le 27/10/2012 13:11, Stephane Legras-Decussy a écrit :
c'est pas du tout ma spécialité l'info système mais
j'ai toujours été dubitatif devant le remplissage de trou
sans fragmenter ...
Le système recherche un trou de taille suffisante pour accueillir le
fichier en entier, au lieu de le découper en petits morceaux pour
remplir plusieurs petits trous. Il ne sera découpé que s'il ne reste pas
de trou assez grand, c'est à dire quand la partition approche de la
saturation.
non, bien avant. Il y aura beaucoup plus de trous, plus petits ...
En plus c'est idiot. Découper un VOB de 2 GO en 5 fragments n'a jamais
ralenti personne.
--
One computer and three operating systems, not the other way round.
One wife and many hotels, not the other way round ! ;-)
Le 27/10/2012 13:11, Stephane Legras-Decussy a écrit :
c'est pas du tout ma spécialité l'info système mais j'ai toujours été dubitatif devant le remplissage de trou sans fragmenter ...
Le système recherche un trou de taille suffisante pour accueillir le fichier en entier, au lieu de le découper en petits morceaux pour remplir plusieurs petits trous. Il ne sera découpé que s'il ne reste pas de trou assez grand, c'est à dire quand la partition approche de la saturation.
non, bien avant. Il y aura beaucoup plus de trous, plus petits ...
En plus c'est idiot. Découper un VOB de 2 GO en 5 fragments n'a jamais ralenti personne.
-- One computer and three operating systems, not the other way round. One wife and many hotels, not the other way round ! ;-)
Laszlo Lebrun
On 27.10.2012 12:16, YouDontNeedToKnowButItsNoëlle wrote:
Le 27/10/12 02:03, Stephane Legras-Decussy a écrit :
alors ça revient un peu au même si tu as beaucoup de fichiers pour accomplir A, non ?
Non. (réponse courte). Question : la réponse longue t’intéresse ou c'est juste comme ça pour voir si je la connais ? La réponse longue explicative demande un peu de temps de rédaction de ma part : je me tâte pour l'effort. Je commence à avoir faim.
Noëlle Adam
C'est pas grave, on va attendre qu t'aies fini ton 4heures et même la sieste qui va avec. Mais on aimerait la réponse.
-- One computer and three operating systems, not the other way round. One wife and many hotels, not the other way round ! ;-)
On 27.10.2012 12:16, YouDontNeedToKnowButItsNoëlle wrote:
Le 27/10/12 02:03, Stephane Legras-Decussy a écrit :
alors ça revient un peu au même si tu as beaucoup de fichiers pour accomplir A, non ?
Non. (réponse courte).
Question : la réponse longue t’intéresse ou c'est juste comme ça pour
voir si je la connais ?
La réponse longue explicative demande un peu de temps de rédaction de ma
part : je me tâte pour l'effort. Je commence à avoir faim.
Noëlle Adam
C'est pas grave, on va attendre qu t'aies fini ton 4heures et même la
sieste qui va avec. Mais on aimerait la réponse.
--
One computer and three operating systems, not the other way round.
One wife and many hotels, not the other way round ! ;-)
On 27.10.2012 12:16, YouDontNeedToKnowButItsNoëlle wrote:
Le 27/10/12 02:03, Stephane Legras-Decussy a écrit :
alors ça revient un peu au même si tu as beaucoup de fichiers pour accomplir A, non ?
Non. (réponse courte). Question : la réponse longue t’intéresse ou c'est juste comme ça pour voir si je la connais ? La réponse longue explicative demande un peu de temps de rédaction de ma part : je me tâte pour l'effort. Je commence à avoir faim.
Noëlle Adam
C'est pas grave, on va attendre qu t'aies fini ton 4heures et même la sieste qui va avec. Mais on aimerait la réponse.
-- One computer and three operating systems, not the other way round. One wife and many hotels, not the other way round ! ;-)
Laszlo Lebrun
On 27.10.2012 15:09, £g wrote:
"YouDontNeedToKnowButItsNoëlle" a écrit dans le message de news: k6gcg1$h6s$
Le 27/10/12 10:07, Laszlo Lebrun a écrit :
On 27.10.2012 09:53, Olivier B. wrote:
poussons le raisonnement à l'extreme, je place tout dans un seul fichier, j'ai aucune fragmentation, simple.
Poussons le raisonnement a l'extrême, si je mets mes fragments _sur des disques différents_ je gagne du temps.
Si tu met les bits sur des disques différents tu gagne un temps fou : raid.
Tu peux encore diviser le temps par deux si tu place les bits zéro sur un DD et les bits un sur l'autre, ainsi tu gagne le temps de recherche.
La raison de la défragmentation est la force centrifuge due à la rotation du DD, plus de 7000 tours, avec cette force dite << skating >> pousse les données vers l'extérieure un peu n'importe où, la défragmentation les ramènes au centre.
Et si vous ne croyez pas celle-la, je peux toujours réfléchir à une autre, plus * énorme *.
Moi j'aimais bien la brêle de fifo-lifo compilation des segments et compagnie. Ca m'a fait bien rigoler...
-- One computer and three operating systems, not the other way round. One wife and many hotels, not the other way round ! ;-)
On 27.10.2012 15:09, £g wrote:
"YouDontNeedToKnowButItsNoëlle" <FautLaDemander@simple.org> a écrit dans
le message de news: k6gcg1$h6s$3@speranza.aioe.org...
Le 27/10/12 10:07, Laszlo Lebrun a écrit :
On 27.10.2012 09:53, Olivier B. wrote:
poussons le raisonnement à l'extreme, je place tout dans un seul
fichier, j'ai aucune fragmentation, simple.
Poussons le raisonnement a l'extrême, si je mets mes fragments _sur
des
disques différents_ je gagne du temps.
Si tu met les bits sur des disques différents tu gagne un temps fou :
raid.
Tu peux encore diviser le temps par deux si tu place les bits zéro sur
un DD et les bits un sur l'autre, ainsi tu gagne le temps de recherche.
La raison de la défragmentation est la force centrifuge due à la
rotation du DD, plus de 7000 tours, avec cette force dite << skating >>
pousse les données vers l'extérieure un peu n'importe où, la
défragmentation les ramènes au centre.
Et si vous ne croyez pas celle-la, je peux toujours réfléchir à une
autre, plus * énorme *.
Moi j'aimais bien la brêle de fifo-lifo compilation des segments et
compagnie.
Ca m'a fait bien rigoler...
--
One computer and three operating systems, not the other way round.
One wife and many hotels, not the other way round ! ;-)
"YouDontNeedToKnowButItsNoëlle" a écrit dans le message de news: k6gcg1$h6s$
Le 27/10/12 10:07, Laszlo Lebrun a écrit :
On 27.10.2012 09:53, Olivier B. wrote:
poussons le raisonnement à l'extreme, je place tout dans un seul fichier, j'ai aucune fragmentation, simple.
Poussons le raisonnement a l'extrême, si je mets mes fragments _sur des disques différents_ je gagne du temps.
Si tu met les bits sur des disques différents tu gagne un temps fou : raid.
Tu peux encore diviser le temps par deux si tu place les bits zéro sur un DD et les bits un sur l'autre, ainsi tu gagne le temps de recherche.
La raison de la défragmentation est la force centrifuge due à la rotation du DD, plus de 7000 tours, avec cette force dite << skating >> pousse les données vers l'extérieure un peu n'importe où, la défragmentation les ramènes au centre.
Et si vous ne croyez pas celle-la, je peux toujours réfléchir à une autre, plus * énorme *.
Moi j'aimais bien la brêle de fifo-lifo compilation des segments et compagnie. Ca m'a fait bien rigoler...
-- One computer and three operating systems, not the other way round. One wife and many hotels, not the other way round ! ;-)
Laszlo Lebrun
On 27.10.2012 12:08, pehache wrote:
Il me semble avoir lu (où ? je ne sais plus, mais dans mon souvenir il s'agissait d'une source sérieuse) qu'OS X désactivait la defrag automatique quand il détectait un SSD.
... un SSD *Apple*. Pour les autres non, tant pis pour eux.
-- One computer and three operating systems, not the other way round. One wife and many hotels, not the other way round ! ;-)
On 27.10.2012 12:08, pehache wrote:
Il me semble avoir lu (où ? je ne sais plus, mais dans mon souvenir il
s'agissait d'une source sérieuse) qu'OS X désactivait la defrag
automatique quand il détectait un SSD.
... un SSD *Apple*.
Pour les autres non, tant pis pour eux.
--
One computer and three operating systems, not the other way round.
One wife and many hotels, not the other way round ! ;-)
Il me semble avoir lu (où ? je ne sais plus, mais dans mon souvenir il s'agissait d'une source sérieuse) qu'OS X désactivait la defrag automatique quand il détectait un SSD.
... un SSD *Apple*. Pour les autres non, tant pis pour eux.
-- One computer and three operating systems, not the other way round. One wife and many hotels, not the other way round ! ;-)
jp willm
Hello,
Le 27/10/2012 13:08, Alf92 a écrit :
tu utilises encore tes disques de 2002 ??
Nous venons de remplacer le PC de ma femme qui tournait avec un disque IDE 80 Go de 2002. La partition /home est la même depuis le début et cette partition était remplie à 70 % environ depuis le début (transfert des anciennes données) lors de la mise en service de ce disque.
Bien sûr, ces données ne sont pas restées inchangées, car au fil des ans on ajoute et supprime pas mal de fichiers.
Nous venons de remplacer le PC de ma femme qui tournait avec un disque
IDE 80 Go de 2002. La partition /home est la même depuis le début et
cette partition était remplie à 70 % environ depuis le début (transfert
des anciennes données) lors de la mise en service de ce disque.
Bien sûr, ces données ne sont pas restées inchangées, car au fil des ans
on ajoute et supprime pas mal de fichiers.
Nous venons de remplacer le PC de ma femme qui tournait avec un disque IDE 80 Go de 2002. La partition /home est la même depuis le début et cette partition était remplie à 70 % environ depuis le début (transfert des anciennes données) lors de la mise en service de ce disque.
Bien sûr, ces données ne sont pas restées inchangées, car au fil des ans on ajoute et supprime pas mal de fichiers.
Ça explique bien pourquoi Windows fragmente bien plus qu'Unix.
il est évoqué dans cet article la fragmentation de la mémoire vive. j'avoue ne pas comprendre en quoi c'est un problème...
la mémoire est bien plus rapide en lecture continue ou une technique prépare déjà les bloc d'après, lorsque tu change d'adresse tu dois attendre queques cycles car la nouvelle adresse n'a pas pu etre préparée.
-- pas de turlututu. apres l'@robase
On Sat, 27 Oct 2012 14:39:34 +0200, "Alf92" <alf921@gmail.com> wrote:
"Ghost-Rider" <Ghost-Rider@compuserve.com> a écrit
Ça explique bien pourquoi Windows fragmente bien plus qu'Unix.
il est évoqué dans cet article la fragmentation de la mémoire vive.
j'avoue ne pas comprendre en quoi c'est un problème...
la mémoire est bien plus rapide en lecture continue ou une technique
prépare déjà les bloc d'après, lorsque tu change d'adresse tu dois
attendre queques cycles car la nouvelle adresse n'a pas pu etre
préparée.
Ça explique bien pourquoi Windows fragmente bien plus qu'Unix.
il est évoqué dans cet article la fragmentation de la mémoire vive. j'avoue ne pas comprendre en quoi c'est un problème...
la mémoire est bien plus rapide en lecture continue ou une technique prépare déjà les bloc d'après, lorsque tu change d'adresse tu dois attendre queques cycles car la nouvelle adresse n'a pas pu etre préparée.
