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 ! ;-)
Le 27/10/12 02:09, Stephane Legras-Decussy a écrit :
Le 26/10/2012 18:23, YouDontNeedToKnowButItsNoëlle a écrit :
Le 26/10/12 18:02, SbM a écrit :
Mauvaise logique. Revoir logique.
Je dirais revoir cours système.
c'est par un argument...
Non, c'est une suggestion.
Noëlle Adam
Alf92
"Laszlo Lebrun" a écrit
Sous Linux, cette opération n'est pas nécessaire, car de par leur conception, les systèmes de fichiers ext3 ou reiserfs (par exemple) *vont avoir une tendance naturelle à n'écrire que là où il y aura la place de le faire*, et d'optimiser l'espace disque consommé.
Mouarf! NTFS fait ca depuis 1991 lui aussi on n'en est pls a Fat16 depuis longtemps. Me font marrer ces gugusses avec leurs arguments de 1975 comme si lmeonde n'avait pas évolué...
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? On le réecrit ailleurs "là où il y aura la place de le faire". On remplace alors la fragmentation par la dispersion. C'est mieux? Et quant il n'a plus que des trous?
+1
"Laszlo Lebrun" <lazlo_lebrun@laszlomail.com> a écrit
Sous Linux, cette opération n'est pas nécessaire, car de par leur conception,
les systèmes de fichiers ext3 ou reiserfs (par exemple) *vont avoir une
tendance naturelle à n'écrire que là où il y aura la place de le faire*, et
d'optimiser l'espace disque consommé.
Mouarf!
NTFS fait ca depuis 1991 lui aussi on n'en est pls a Fat16 depuis longtemps.
Me font marrer ces gugusses avec leurs arguments de 1975 comme si lmeonde
n'avait pas évolué...
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?
On le réecrit ailleurs "là où il y aura la place de le faire".
On remplace alors la fragmentation par la dispersion. C'est mieux?
Et quant il n'a plus que des trous?
Sous Linux, cette opération n'est pas nécessaire, car de par leur conception, les systèmes de fichiers ext3 ou reiserfs (par exemple) *vont avoir une tendance naturelle à n'écrire que là où il y aura la place de le faire*, et d'optimiser l'espace disque consommé.
Mouarf! NTFS fait ca depuis 1991 lui aussi on n'en est pls a Fat16 depuis longtemps. Me font marrer ces gugusses avec leurs arguments de 1975 comme si lmeonde n'avait pas évolué...
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? On le réecrit ailleurs "là où il y aura la place de le faire". On remplace alors la fragmentation par la dispersion. C'est mieux? Et quant il n'a plus que des trous?
+1
YouDontNeedToKnowButItsNoëlle
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.
Noëlle Adam
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.
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.
Noëlle Adam
Pierre Maurette
Laszlo Lebrun :
On 27.10.2012 07:42, £g wrote:
"Stephane Legras-Decussy" a écrit dans le message de news: k6f8d3$86o$
Le 26/10/2012 16:47, YouDontNeedToKnowButItsNoëlle a écrit :
Le 26/10/12 16:30, Laszlo Lebrun a écrit :
- OSX est déja d'avantage "fragmenté" que Windows (en nombre de fichiers)
Il y a plus de fichiers donc c'est plus fragmenté ? Est-ce que je te lis correctement ? J'ai zappé quelque chose ? C'est bien ça que tu racontes ?
si on considère que la fragmentation c'est le déplacement lourdingue de la tête de lecture pour une tache A, alors ça revient un peu au même si tu as beaucoup de fichiers pour accomplir A, non ?
non, une procédure ou programme fragmenté oblige, pour recomposer cette procédure/prg à des accès à la pile, quel soit lifo ou fifo, dans le cas du non fragmenté, donc complet, l'ordre procédure ou prg est compilé et exécuté immédiatement.
Ca ca en jette!
...Quoique comme dirait Bedos!!
Devos, non ?
Je vois pas très bien ce que tes elucubrations lifi / fifo viennent a faire la dedans et bien peu de programmes compilent a l'execution. Quand "à tes accès à la pile" laisse moi doucement rigoler: on est en nano-secondes là!
Quand on n'y connait rien on va pas faire un copier coller de n'importe quoi pour faire savant.
N'est-il pas ?
-- Pierre Maurette
Laszlo Lebrun :
On 27.10.2012 07:42, £g wrote:
"Stephane Legras-Decussy" <admin@facebook.com> a écrit dans le message
de news: k6f8d3$86o$1@speranza.aioe.org...
Le 26/10/2012 16:47, YouDontNeedToKnowButItsNoëlle a écrit :
Le 26/10/12 16:30, Laszlo Lebrun a écrit :
- OSX est déja d'avantage "fragmenté" que Windows (en nombre de
fichiers)
Il y a plus de fichiers donc c'est plus fragmenté ? Est-ce que je te
lis
correctement ? J'ai zappé quelque chose ? C'est bien ça que tu
racontes ?
si on considère que la fragmentation c'est le déplacement
lourdingue de la tête de lecture pour une tache A, alors ça revient
un peu au même si tu as beaucoup de fichiers pour accomplir A, non ?
non,
une procédure ou programme fragmenté oblige, pour recomposer cette
procédure/prg à des accès à la pile, quel soit lifo ou fifo, dans le cas
du non fragmenté, donc complet, l'ordre procédure ou prg est compilé et
exécuté immédiatement.
Ca ca en jette!
...Quoique comme dirait Bedos!!
Devos, non ?
Je vois pas très bien ce que tes elucubrations lifi / fifo viennent a faire
la dedans et bien peu de programmes compilent a l'execution.
Quand "à tes accès à la pile" laisse moi doucement rigoler: on est en
nano-secondes là!
Quand on n'y connait rien on va pas faire un copier coller de n'importe quoi
pour faire savant.
"Stephane Legras-Decussy" a écrit dans le message de news: k6f8d3$86o$
Le 26/10/2012 16:47, YouDontNeedToKnowButItsNoëlle a écrit :
Le 26/10/12 16:30, Laszlo Lebrun a écrit :
- OSX est déja d'avantage "fragmenté" que Windows (en nombre de fichiers)
Il y a plus de fichiers donc c'est plus fragmenté ? Est-ce que je te lis correctement ? J'ai zappé quelque chose ? C'est bien ça que tu racontes ?
si on considère que la fragmentation c'est le déplacement lourdingue de la tête de lecture pour une tache A, alors ça revient un peu au même si tu as beaucoup de fichiers pour accomplir A, non ?
non, une procédure ou programme fragmenté oblige, pour recomposer cette procédure/prg à des accès à la pile, quel soit lifo ou fifo, dans le cas du non fragmenté, donc complet, l'ordre procédure ou prg est compilé et exécuté immédiatement.
Ca ca en jette!
...Quoique comme dirait Bedos!!
Devos, non ?
Je vois pas très bien ce que tes elucubrations lifi / fifo viennent a faire la dedans et bien peu de programmes compilent a l'execution. Quand "à tes accès à la pile" laisse moi doucement rigoler: on est en nano-secondes là!
Quand on n'y connait rien on va pas faire un copier coller de n'importe quoi pour faire savant.
N'est-il pas ?
-- Pierre Maurette
Alf92
"YouDontNeedToKnowButItsNoëlle" a écrit
Le 26/10/12 21:03, Laszlo Lebrun a écrit :
Je dirais revoir cours système.
Noëlle Adam
T'as pas la page par hasard?
Tu sais te servir d'un moteur de recherche ?
pourquoi chercher 2 heures avec un robot quand l'interlocuteur humain peut te donner immédiatement l'info. en plus un humain c'est plus sympa qu'un robot. dingue non ?
"YouDontNeedToKnowButItsNoëlle" <FautLaDemander@simple.org> a écrit
Le 26/10/12 21:03, Laszlo Lebrun a écrit :
Je dirais revoir cours système.
Noëlle Adam
T'as pas la page par hasard?
Tu sais te servir d'un moteur de recherche ?
pourquoi chercher 2 heures avec un robot quand l'interlocuteur humain peut te
donner immédiatement l'info.
en plus un humain c'est plus sympa qu'un robot.
dingue non ?
pourquoi chercher 2 heures avec un robot quand l'interlocuteur humain peut te donner immédiatement l'info. en plus un humain c'est plus sympa qu'un robot. dingue non ?
Stephane Legras-Decussy
Le 27/10/2012 07:42, £g a écrit :
une procédure ou programme fragmenté oblige, pour recomposer cette procédure/prg à des accès à la pile, quel soit lifo ou fifo, dans le cas du non fragmenté, donc complet, l'ordre procédure ou prg est compilé et exécuté immédiatement.
c'est completement dérisoire par rapport à l'ordre de grandeur des temps mécaniques d'une tête de lecture ...
Le 27/10/2012 07:42, £g a écrit :
une procédure ou programme fragmenté oblige, pour recomposer cette
procédure/prg à des accès à la pile, quel soit lifo ou fifo, dans le cas
du non fragmenté, donc complet, l'ordre procédure ou prg est compilé et
exécuté immédiatement.
c'est completement dérisoire par rapport à l'ordre de grandeur
des temps mécaniques d'une tête de lecture ...
une procédure ou programme fragmenté oblige, pour recomposer cette procédure/prg à des accès à la pile, quel soit lifo ou fifo, dans le cas du non fragmenté, donc complet, l'ordre procédure ou prg est compilé et exécuté immédiatement.
c'est completement dérisoire par rapport à l'ordre de grandeur des temps mécaniques d'une tête de lecture ...
François
Le 27/10/2012 10:52, Laszlo Lebrun a écrit :
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).
-- François
Le 27/10/2012 10:52, Laszlo Lebrun a écrit :
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).
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).
-- François
Pierre Maurette
Laszlo Lebrun :
je viens de faire (comme tous les mois) la defrag de mes deux machines Windows.
Une opération de défragmentation mensuelle, utile ou pas, peut être efficacement remplacée par l'intégration au processus de sauvegarde d'une copie intelligemment ordonnée vers un support effacé. Par exemple passer de défragmentation de A (actif) puis copie vers B (backup) à copie de Apair vers B, restauration par fichier de B vers Aimpair, etc. Je ne veux pas nourrir ce troll velu, donc pas plus de détails.
-- Pierre Maurette
Laszlo Lebrun :
je viens de faire (comme tous les mois) la defrag de mes deux machines
Windows.
Une opération de défragmentation mensuelle, utile ou pas, peut être
efficacement remplacée par l'intégration au processus de sauvegarde
d'une copie intelligemment ordonnée vers un support effacé. Par exemple
passer de défragmentation de A (actif) puis copie vers B (backup) à
copie de Apair vers B, restauration par fichier de B vers Aimpair, etc.
Je ne veux pas nourrir ce troll velu, donc pas plus de détails.
je viens de faire (comme tous les mois) la defrag de mes deux machines Windows.
Une opération de défragmentation mensuelle, utile ou pas, peut être efficacement remplacée par l'intégration au processus de sauvegarde d'une copie intelligemment ordonnée vers un support effacé. Par exemple passer de défragmentation de A (actif) puis copie vers B (backup) à copie de Apair vers B, restauration par fichier de B vers Aimpair, etc. Je ne veux pas nourrir ce troll velu, donc pas plus de détails.
-- Pierre Maurette
Alf92
"jp willm" a écrit
"je n'ai jamais eu à formater,"
A défragmenter je voulais dire :o)
tu utilises encore tes disques de 2002 ??
"jp willm" <nicole.jeanpaul.willm@wanadoo.fr> a écrit
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? On le réecrit ailleurs "là où il y aura la place de le faire". On remplace alors la fragmentation par la dispersion. C'est mieux? Et quant il n'a plus que des trous?
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 27/10/2012 10:52, Laszlo Lebrun a écrit :
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?
On le réecrit ailleurs "là où il y aura la place de le faire".
On remplace alors la fragmentation par la dispersion. C'est mieux?
Et quant il n'a plus que des trous?
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 ...
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? On le réecrit ailleurs "là où il y aura la place de le faire". On remplace alors la fragmentation par la dispersion. C'est mieux? Et quant il n'a plus que des trous?
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 ...
