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/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.
Et quand tu ajoute des données au bout d'un fichier existant alors qu'il n'y a pas de cluster contigu dispo ?
Tu fais quoi ?
-- @+ Ascadix adresse @mail valide, mais ajoutez "sesame" dans l'objet pour que ça arrive.
François a pensé très fort :
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.
Et quand tu ajoute des données au bout d'un fichier existant alors
qu'il n'y a pas de cluster contigu dispo ?
Tu fais quoi ?
--
@+
Ascadix
adresse @mail valide, mais ajoutez "sesame" dans l'objet pour que ça
arrive.
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.
Et quand tu ajoute des données au bout d'un fichier existant alors qu'il n'y a pas de cluster contigu dispo ?
Tu fais quoi ?
-- @+ Ascadix adresse @mail valide, mais ajoutez "sesame" dans l'objet pour que ça arrive.
Alf92
"YouDontNeedToKnowButItsNoëlle" a écrit
Je pense qu'il voulait dire que tout ce qui est opératif, ça lit/écrit essentiellement dans la ram, et même dans les caches et la pile du processeur. Là, que l'accès soit séquentiel ou pas ça ne change rien. Si on en est a swapper sur disque en exécution, c'est un autre problème, faut plutôt gonfler la ram. En pratique, j'imagine qu'on peut donner une seconde jeunesse à une machine qui swappe et qui ne peut plus accueillir de mémoire en plus (genre les slots sont tous occupés) en collant dedans un SSD rien que pour le swap. Même un petit peut faire de l'effet. Avec un peu plus gros, le système, les applis les plus fréquentes et un peu de swap, wrroooom. Le DD classique reste un goulot pour les données, mais ça doit déjà bien booster à faible investissement. Est-ce qu'on peut indiquer spécifiquement un disque (SSD) par exemple comme cache pour un plus autre + lent je n'ai pas idée. C'est à dire l'idée me semble à faire mais possible et comment précisment je ne sais pas. Un piti daemon ? Allez les bricoleurs.
AMHA utiliser un SSD pour faire du swapp n'est pas une bonne idée. un fichier swap ça sert bcp, or un SSD n'aime pas bcp servir. pour du cache ça serait encore pire.
de toute manière le SSD n'est clairement pas une solution d'avenir.
"YouDontNeedToKnowButItsNoëlle" <FautLaDemander@simple.org> a écrit
Je pense qu'il voulait dire que tout ce qui est opératif, ça lit/écrit
essentiellement dans la ram, et même dans les caches et la pile du processeur.
Là, que l'accès soit séquentiel ou pas ça ne change rien.
Si on en est a swapper sur disque en exécution, c'est un autre problème, faut
plutôt gonfler la ram.
En pratique, j'imagine qu'on peut donner une seconde jeunesse à une machine
qui swappe et qui ne peut plus accueillir de mémoire en plus (genre les slots
sont tous occupés) en collant dedans un SSD rien que pour le swap. Même un
petit peut faire de l'effet. Avec un peu plus gros, le système, les applis
les plus fréquentes et un peu de swap, wrroooom. Le DD classique reste un
goulot pour les données, mais ça doit déjà bien booster à faible
investissement.
Est-ce qu'on peut indiquer spécifiquement un disque (SSD) par exemple comme
cache pour un plus autre + lent je n'ai pas idée. C'est à dire l'idée me
semble à faire mais possible et comment précisment je ne sais pas.
Un piti daemon ? Allez les bricoleurs.
AMHA utiliser un SSD pour faire du swapp n'est pas une bonne idée.
un fichier swap ça sert bcp, or un SSD n'aime pas bcp servir.
pour du cache ça serait encore pire.
de toute manière le SSD n'est clairement pas une solution d'avenir.
Je pense qu'il voulait dire que tout ce qui est opératif, ça lit/écrit essentiellement dans la ram, et même dans les caches et la pile du processeur. Là, que l'accès soit séquentiel ou pas ça ne change rien. Si on en est a swapper sur disque en exécution, c'est un autre problème, faut plutôt gonfler la ram. En pratique, j'imagine qu'on peut donner une seconde jeunesse à une machine qui swappe et qui ne peut plus accueillir de mémoire en plus (genre les slots sont tous occupés) en collant dedans un SSD rien que pour le swap. Même un petit peut faire de l'effet. Avec un peu plus gros, le système, les applis les plus fréquentes et un peu de swap, wrroooom. Le DD classique reste un goulot pour les données, mais ça doit déjà bien booster à faible investissement. Est-ce qu'on peut indiquer spécifiquement un disque (SSD) par exemple comme cache pour un plus autre + lent je n'ai pas idée. C'est à dire l'idée me semble à faire mais possible et comment précisment je ne sais pas. Un piti daemon ? Allez les bricoleurs.
AMHA utiliser un SSD pour faire du swapp n'est pas une bonne idée. un fichier swap ça sert bcp, or un SSD n'aime pas bcp servir. pour du cache ça serait encore pire.
de toute manière le SSD n'est clairement pas une solution d'avenir.
Ascadix
YouDontNeedToKnowButItsNoëlle avait prétendu :
Le 27/10/12 12:23, Stephane Legras-Decussy a écrit :
c'est completement dérisoire par rapport à l'ordre de grandeur des temps mécaniques d'une tête de lecture ...
Exactement. Je pense qu'il voulait dire que tout ce qui est opératif, ça lit/écrit essentiellement dans la ram, et même dans les caches et la pile du processeur. Là, que l'accès soit séquentiel ou pas ça ne change rien. Si on en est a swapper sur disque en exécution, c'est un autre problème, faut plutôt gonfler la ram.
En pratique, j'imagine qu'on peut donner une seconde jeunesse à une machine qui swappe et qui ne peut plus accueillir de mémoire en plus (genre les slots sont tous occupés) en collant dedans un SSD rien que pour le swap. Même un petit peut faire de l'effet. Avec un peu plus gros, le système, les applis les plus fréquentes et un peu de swap, wrroooom. Le DD classique reste un goulot pour les données, mais ça doit déjà bien booster à faible investissement.
rien que pour le swap, ça semble à peu disproportionné, et vu les prix est-ce réélement rentable ?
Bien souvent, on peut commencer par mettre un peu les pattes dans la config, virer un tas de trucs obsolétes, et éventuellement adapter ses habitudes comme par ex choisir des softs moin gaspilleur de ressources, réduire le multi-tâche ...
Est-ce qu'on peut indiquer spécifiquement un disque (SSD) par exemple comme cache pour un plus autre + lent je n'ai pas idée. C'est à dire l'idée me semble à faire mais possible et comment précisment je ne sais pas.
Y a 3 trucs qui collent +/- à ton idée si je t'ai bien suivit:
- le ReadyBoost de Vista/7 (avec un support flash, genre clef USB ou pkoi un p'tit SSD)
- les disques hybrides
- L'utilsiation d'un SSD comme cache, ça existe déjà, et les fabricant de SSD qui proposent ça utilisent souvent en fait le soft de chez NVELO (http://www.nvelo.com/dataplex)
Pour les hybrides, y a un p'tit comparatif là: http://www.jmax-hardware.com/tests/comparatif-hdd-hybrid-ssd.html
Un piti daemon ? Allez les bricoleurs.
Coté Windows, le daemon s'appele ReadyBoost et il existe déjà.
Coté disque hybride, il me semble que c'est indépendant de l'OS, ça parle pas de driver spécifique ou autres subtilité soft.
Coté SSD en mode cache, le soft marche avec 7 et 8 fenêtres, pas les plumes ni les pommes.
Noëlle Adam
-- @+ Ascadix adresse @mail valide, mais ajoutez "sesame" dans l'objet pour que ça arrive.
YouDontNeedToKnowButItsNoëlle avait prétendu :
Le 27/10/12 12:23, Stephane Legras-Decussy a écrit :
c'est completement dérisoire par rapport à l'ordre de grandeur
des temps mécaniques d'une tête de lecture ...
Exactement.
Je pense qu'il voulait dire que tout ce qui est opératif, ça lit/écrit
essentiellement dans la ram, et même dans les caches et la pile du
processeur. Là, que l'accès soit séquentiel ou pas ça ne change rien.
Si on en est a swapper sur disque en exécution, c'est un autre problème, faut
plutôt gonfler la ram.
En pratique, j'imagine qu'on peut donner une seconde jeunesse à une machine
qui swappe et qui ne peut plus accueillir de mémoire en plus (genre les slots
sont tous occupés) en collant dedans un SSD rien que pour le swap. Même un
petit peut faire de l'effet. Avec un peu plus gros, le système, les applis
les plus fréquentes et un peu de swap, wrroooom. Le DD classique reste un
goulot pour les données, mais ça doit déjà bien booster à faible
investissement.
rien que pour le swap, ça semble à peu disproportionné, et vu les prix
est-ce réélement rentable ?
Bien souvent, on peut commencer par mettre un peu les pattes dans la
config, virer un tas de trucs obsolétes, et éventuellement adapter ses
habitudes comme par ex choisir des softs moin gaspilleur de ressources,
réduire le multi-tâche ...
Est-ce qu'on peut indiquer spécifiquement un disque (SSD) par exemple comme
cache pour un plus autre + lent je n'ai pas idée. C'est à dire l'idée me
semble à faire mais possible et comment précisment je ne sais pas.
Y a 3 trucs qui collent +/- à ton idée si je t'ai bien suivit:
- le ReadyBoost de Vista/7 (avec un support flash, genre clef USB ou
pkoi un p'tit SSD)
- les disques hybrides
- L'utilsiation d'un SSD comme cache, ça existe déjà, et les fabricant
de SSD qui proposent ça utilisent souvent en fait le soft de chez NVELO
(http://www.nvelo.com/dataplex)
Pour les hybrides, y a un p'tit comparatif là:
http://www.jmax-hardware.com/tests/comparatif-hdd-hybrid-ssd.html
Un piti daemon ? Allez les bricoleurs.
Coté Windows, le daemon s'appele ReadyBoost et il existe déjà.
Coté disque hybride, il me semble que c'est indépendant de l'OS, ça
parle pas de driver spécifique ou autres subtilité soft.
Coté SSD en mode cache, le soft marche avec 7 et 8 fenêtres, pas les
plumes ni les pommes.
Noëlle Adam
--
@+
Ascadix
adresse @mail valide, mais ajoutez "sesame" dans l'objet pour que ça
arrive.
Le 27/10/12 12:23, Stephane Legras-Decussy a écrit :
c'est completement dérisoire par rapport à l'ordre de grandeur des temps mécaniques d'une tête de lecture ...
Exactement. Je pense qu'il voulait dire que tout ce qui est opératif, ça lit/écrit essentiellement dans la ram, et même dans les caches et la pile du processeur. Là, que l'accès soit séquentiel ou pas ça ne change rien. Si on en est a swapper sur disque en exécution, c'est un autre problème, faut plutôt gonfler la ram.
En pratique, j'imagine qu'on peut donner une seconde jeunesse à une machine qui swappe et qui ne peut plus accueillir de mémoire en plus (genre les slots sont tous occupés) en collant dedans un SSD rien que pour le swap. Même un petit peut faire de l'effet. Avec un peu plus gros, le système, les applis les plus fréquentes et un peu de swap, wrroooom. Le DD classique reste un goulot pour les données, mais ça doit déjà bien booster à faible investissement.
rien que pour le swap, ça semble à peu disproportionné, et vu les prix est-ce réélement rentable ?
Bien souvent, on peut commencer par mettre un peu les pattes dans la config, virer un tas de trucs obsolétes, et éventuellement adapter ses habitudes comme par ex choisir des softs moin gaspilleur de ressources, réduire le multi-tâche ...
Est-ce qu'on peut indiquer spécifiquement un disque (SSD) par exemple comme cache pour un plus autre + lent je n'ai pas idée. C'est à dire l'idée me semble à faire mais possible et comment précisment je ne sais pas.
Y a 3 trucs qui collent +/- à ton idée si je t'ai bien suivit:
- le ReadyBoost de Vista/7 (avec un support flash, genre clef USB ou pkoi un p'tit SSD)
- les disques hybrides
- L'utilsiation d'un SSD comme cache, ça existe déjà, et les fabricant de SSD qui proposent ça utilisent souvent en fait le soft de chez NVELO (http://www.nvelo.com/dataplex)
Pour les hybrides, y a un p'tit comparatif là: http://www.jmax-hardware.com/tests/comparatif-hdd-hybrid-ssd.html
Un piti daemon ? Allez les bricoleurs.
Coté Windows, le daemon s'appele ReadyBoost et il existe déjà.
Coté disque hybride, il me semble que c'est indépendant de l'OS, ça parle pas de driver spécifique ou autres subtilité soft.
Coté SSD en mode cache, le soft marche avec 7 et 8 fenêtres, pas les plumes ni les pommes.
Noëlle Adam
-- @+ Ascadix adresse @mail valide, mais ajoutez "sesame" dans l'objet pour que ça arrive.
Richard
Stacker marchait comme ça à l'époque de MS DOS 5 / Win 3.1
Ah... Stacker ! Un outil merveilleux pour l'époque. Nostalgie.....
Stacker marchait comme ça à l'époque de MS DOS 5 / Win 3.1
Ah... Stacker ! Un outil merveilleux pour l'époque.
Nostalgie.....
Stacker marchait comme ça à l'époque de MS DOS 5 / Win 3.1
Ah... Stacker ! Un outil merveilleux pour l'époque. Nostalgie.....
Ascadix
Laszlo Lebrun avait écrit le 27/10/2012 :
On 27.10.2012 02:03, Stephane Legras-Decussy wrote:
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 ?
à moins qu'il y ait 100 000 wallpaper fournis qui explique la différence .. ;-)
Bien sûr, si les fichiers sont pas utilisés... Mais la défrag, c'est pareil, ca te recolle des fichiers VOB que tu regardes tous les 3 ans.
ça dépend des defrag, coté Windows avec le défrag intégré par ex, il regroupe les fragments inférieurs à 64 Mo, mais une fois qu'il à des fragments de 64 Mo, il ne tente pas d'insister au motif que le temps de defrag serais disproportionné par rapport au gain apporté en accés ultérieurs à ces fichiers.
Il prend aussis en compte les stats d'accés/utilsiation aux fichier de façon bien plus fine que juste regarder la date de modif du fichier pour choisir lesquels il regroupe en début de disque pour accélérer le boot et l'utilisation de la machine.
-- @+ Ascadix adresse @mail valide, mais ajoutez "sesame" dans l'objet pour que ça arrive.
Laszlo Lebrun avait écrit le 27/10/2012 :
On 27.10.2012 02:03, Stephane Legras-Decussy wrote:
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 ?
à moins qu'il y ait 100 000 wallpaper fournis qui explique
la différence .. ;-)
Bien sûr, si les fichiers sont pas utilisés...
Mais la défrag, c'est pareil, ca te recolle des fichiers VOB que tu regardes
tous les 3 ans.
ça dépend des defrag, coté Windows avec le défrag intégré par ex, il
regroupe les fragments inférieurs à 64 Mo, mais une fois qu'il à des
fragments de 64 Mo, il ne tente pas d'insister au motif que le temps de
defrag serais disproportionné par rapport au gain apporté en accés
ultérieurs à ces fichiers.
Il prend aussis en compte les stats d'accés/utilsiation aux fichier de
façon bien plus fine que juste regarder la date de modif du fichier
pour choisir lesquels il regroupe en début de disque pour accélérer le
boot et l'utilisation de la machine.
--
@+
Ascadix
adresse @mail valide, mais ajoutez "sesame" dans l'objet pour que ça
arrive.
On 27.10.2012 02:03, Stephane Legras-Decussy wrote:
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 ?
à moins qu'il y ait 100 000 wallpaper fournis qui explique la différence .. ;-)
Bien sûr, si les fichiers sont pas utilisés... Mais la défrag, c'est pareil, ca te recolle des fichiers VOB que tu regardes tous les 3 ans.
ça dépend des defrag, coté Windows avec le défrag intégré par ex, il regroupe les fragments inférieurs à 64 Mo, mais une fois qu'il à des fragments de 64 Mo, il ne tente pas d'insister au motif que le temps de defrag serais disproportionné par rapport au gain apporté en accés ultérieurs à ces fichiers.
Il prend aussis en compte les stats d'accés/utilsiation aux fichier de façon bien plus fine que juste regarder la date de modif du fichier pour choisir lesquels il regroupe en début de disque pour accélérer le boot et l'utilisation de la machine.
-- @+ Ascadix adresse @mail valide, mais ajoutez "sesame" dans l'objet pour que ça arrive.
Ça explique bien pourquoi Windows fragmente bien plus qu'Unix.
Cet article est une fumisterie.
Déjà, confondre FAT et NTFS, c'est copieux.
Ensuite, faut être profondément débile ou ne rien comprendre au B.A.BA de l'utilisation d'un systéme info pour ignorer (délibérement ou par connerie) le cas des fichiers dont la tailel varie *APRES* leur création sur le FS.
C'est par exemple le cas de tous les fichiers de données sur lesquels on travail en plusieures fois, en ajoutant des données au bout à chaque fois.
Ce truc à du être rédigé par un fan-boy qui ne comprend pas le début de la moitié de ce qu'il à recopié comme un crétin.
Si ext était aussi performant, je ne crois pas que les dév qui se sont occupé de EXT4 auraient mis autant d'ardeur à intégrer enfin de vrai mécanismes de défragmentation dans EXT4.
Je dis "enfin", parceque MS à fait la même connerie avec NT4 en considérant que les mécanismes de *prévention* de la fragmentation sur NTFS seraient suffisants à éviter toute fragmentation. C'est bien sur insuffisant, et même avec une trés bonne prévention de la fragmentation, il y aura quand même fragmentation, et il faut donc prévoir des mécanismes curatifs.
MS à réalisé sa bourde entre NT4 et 2000 et à intégré ces mécanismes curatifs dès Windows 2000 avec la fourniture des API de défragmentation sur NTFS et l'intégration d'un défragmenteur (même light) dans la distrib de l'OS.
Coté Linux, encore une fois, 10 ans de retard pour parvenirt à la même conclusion et prendre les mêmes mesures, intégration de mécanismes de *dé*fragmentation dans l'implémentaiton du FS pour intervenir là ou les mécanismes de *prévention* de la fragmentation ont été insuffisants.
-- @+ Ascadix adresse @mail valide, mais ajoutez "sesame" dans l'objet pour que ça arrive.
Ça explique bien pourquoi Windows fragmente bien plus qu'Unix.
Cet article est une fumisterie.
Déjà, confondre FAT et NTFS, c'est copieux.
Ensuite, faut être profondément débile ou ne rien comprendre au B.A.BA
de l'utilisation d'un systéme info pour ignorer (délibérement ou par
connerie) le cas des fichiers dont la tailel varie *APRES* leur
création sur le FS.
C'est par exemple le cas de tous les fichiers de données sur lesquels
on travail en plusieures fois, en ajoutant des données au bout à chaque
fois.
Ce truc à du être rédigé par un fan-boy qui ne comprend pas le début de
la moitié de ce qu'il à recopié comme un crétin.
Si ext était aussi performant, je ne crois pas que les dév qui se sont
occupé de EXT4 auraient mis autant d'ardeur à intégrer enfin de vrai
mécanismes de défragmentation dans EXT4.
Je dis "enfin", parceque MS à fait la même connerie avec NT4 en
considérant que les mécanismes de *prévention* de la fragmentation sur
NTFS seraient suffisants à éviter toute fragmentation. C'est bien sur
insuffisant, et même avec une trés bonne prévention de la
fragmentation, il y aura quand même fragmentation, et il faut donc
prévoir des mécanismes curatifs.
MS à réalisé sa bourde entre NT4 et 2000 et à intégré ces mécanismes
curatifs dès Windows 2000 avec la fourniture des API de défragmentation
sur NTFS et l'intégration d'un défragmenteur (même light) dans la
distrib de l'OS.
Coté Linux, encore une fois, 10 ans de retard pour parvenirt à la même
conclusion et prendre les mêmes mesures, intégration de mécanismes de
*dé*fragmentation dans l'implémentaiton du FS pour intervenir là ou les
mécanismes de *prévention* de la fragmentation ont été insuffisants.
--
@+
Ascadix
adresse @mail valide, mais ajoutez "sesame" dans l'objet pour que ça
arrive.
Ça explique bien pourquoi Windows fragmente bien plus qu'Unix.
Cet article est une fumisterie.
Déjà, confondre FAT et NTFS, c'est copieux.
Ensuite, faut être profondément débile ou ne rien comprendre au B.A.BA de l'utilisation d'un systéme info pour ignorer (délibérement ou par connerie) le cas des fichiers dont la tailel varie *APRES* leur création sur le FS.
C'est par exemple le cas de tous les fichiers de données sur lesquels on travail en plusieures fois, en ajoutant des données au bout à chaque fois.
Ce truc à du être rédigé par un fan-boy qui ne comprend pas le début de la moitié de ce qu'il à recopié comme un crétin.
Si ext était aussi performant, je ne crois pas que les dév qui se sont occupé de EXT4 auraient mis autant d'ardeur à intégrer enfin de vrai mécanismes de défragmentation dans EXT4.
Je dis "enfin", parceque MS à fait la même connerie avec NT4 en considérant que les mécanismes de *prévention* de la fragmentation sur NTFS seraient suffisants à éviter toute fragmentation. C'est bien sur insuffisant, et même avec une trés bonne prévention de la fragmentation, il y aura quand même fragmentation, et il faut donc prévoir des mécanismes curatifs.
MS à réalisé sa bourde entre NT4 et 2000 et à intégré ces mécanismes curatifs dès Windows 2000 avec la fourniture des API de défragmentation sur NTFS et l'intégration d'un défragmenteur (même light) dans la distrib de l'OS.
Coté Linux, encore une fois, 10 ans de retard pour parvenirt à la même conclusion et prendre les mêmes mesures, intégration de mécanismes de *dé*fragmentation dans l'implémentaiton du FS pour intervenir là ou les mécanismes de *prévention* de la fragmentation ont été insuffisants.
-- @+ Ascadix adresse @mail valide, mais ajoutez "sesame" dans l'objet pour que ça arrive.
Ascadix
Olivier B. a émis l'idée suivante :
On Sat, 27 Oct 2012 13:17:40 +0200, Ghost-Rider wrote:
Ça explique bien pourquoi Windows fragmente bien plus qu'Unix.
En fait, je me demande surtout pourquoi windows ne ferait pas comme unix, on est sur que cet article est juste ?
Cet article est une fumisterie doublé d'une montagne de conneries.
Je viens d'y faire une réponse juste à coté, jette-y un coup d'oeuil si ça t'interesse.
je l'ai lue, je suis d'accord...
-- pas de turlututu. apres l'@robase
Alf92
"Richard" a écrit
Stacker marchait comme ça à l'époque de MS DOS 5 / Win 3.1
Ah... Stacker ! Un outil merveilleux pour l'époque. Nostalgie.....
oui une révolution... souvent imité (notament par M$ avec DBLSPACE puis DRVSPACE, et IBM avec SuperStore), jamais égalé.
genre d'outil qui a complètement disparu depuis une 10aine d'années, quand XP a intégré en natif la fonction "compact". et puis aujourd'hui avec la taille des disques...
"Richard" <garetgv_remove_@skynet.be> a écrit
Stacker marchait comme ça à l'époque de MS DOS 5 / Win 3.1
Ah... Stacker ! Un outil merveilleux pour l'époque.
Nostalgie.....
oui une révolution...
souvent imité (notament par M$ avec DBLSPACE puis DRVSPACE, et IBM avec
SuperStore), jamais égalé.
genre d'outil qui a complètement disparu depuis une 10aine d'années, quand XP a
intégré en natif la fonction "compact".
et puis aujourd'hui avec la taille des disques...
Stacker marchait comme ça à l'époque de MS DOS 5 / Win 3.1
Ah... Stacker ! Un outil merveilleux pour l'époque. Nostalgie.....
oui une révolution... souvent imité (notament par M$ avec DBLSPACE puis DRVSPACE, et IBM avec SuperStore), jamais égalé.
genre d'outil qui a complètement disparu depuis une 10aine d'années, quand XP a intégré en natif la fonction "compact". et puis aujourd'hui avec la taille des disques...
Laszlo Lebrun
On 27.10.2012 17:16, £g wrote:
"Laszlo Lebrun" a écrit dans le message de news: k6gou1$jhv$
Moi j'aimais bien la brêle de fifo-lifo compilation des segments et compagnie. Ca m'a fait bien rigoler...
Attend, c'est pas entièrement fals, de 1 c'est pas les segments qui sont compilés, mais les procédures et programmes.
Maintenant, avec les procédures orientées objets, à chaque objet proposé à cette procédure, il y à identification de la data reçue, puis traitée suivant sa nature par les sous-procédures intéressées, c'est bien une compilation à chaque nouvelle données reçue par cette proc.
Arrete! n'en jette plus! Tes elucubrations n'ont RIEN a voir avec les conséquences d'un fichier fragmenté.
-- 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 17:16, £g wrote:
"Laszlo Lebrun" <lazlo_lebrun@laszlomail.com> a écrit dans le message de
news: k6gou1$jhv$2@tota-refugium.de...
Moi j'aimais bien la brêle de fifo-lifo compilation des segments et
compagnie.
Ca m'a fait bien rigoler...
Attend, c'est pas entièrement fals, de 1 c'est pas les segments qui sont
compilés, mais les procédures et programmes.
Maintenant, avec les procédures orientées objets, à chaque objet proposé
à cette procédure, il y à identification de la data reçue, puis traitée
suivant sa nature par les sous-procédures intéressées, c'est bien une
compilation à chaque nouvelle données reçue par cette proc.
Arrete! n'en jette plus! Tes elucubrations n'ont RIEN a voir avec les
conséquences d'un fichier fragmenté.
--
One computer and three operating systems, not the other way round.
One wife and many hotels, not the other way round ! ;-)
"Laszlo Lebrun" a écrit dans le message de news: k6gou1$jhv$
Moi j'aimais bien la brêle de fifo-lifo compilation des segments et compagnie. Ca m'a fait bien rigoler...
Attend, c'est pas entièrement fals, de 1 c'est pas les segments qui sont compilés, mais les procédures et programmes.
Maintenant, avec les procédures orientées objets, à chaque objet proposé à cette procédure, il y à identification de la data reçue, puis traitée suivant sa nature par les sous-procédures intéressées, c'est bien une compilation à chaque nouvelle données reçue par cette proc.
Arrete! n'en jette plus! Tes elucubrations n'ont RIEN a voir avec les conséquences d'un fichier fragmenté.
-- One computer and three operating systems, not the other way round. One wife and many hotels, not the other way round ! ;-)
