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 ! ;-)
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.
Pas mal, en effet :). Les écolos éteindront le disque qui contient les 0, pour sauver la planète qui penche déjà salement d'un coté.
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 c'est vérifiable : en effet, les fichiers situés dans les secteurs périphériques sont plus fragmentés que les autres. Le milieu du disque est rempli en priorité, par le système installé d'abord. Le noyau au milieu, pas de pépins. Et ça bouchonne sur le périphérique, personne ne peut nier ça.
Et si vous ne croyez pas celle-la, je peux toujours réfléchir à une autre, plus * énorme *.
Yep, ça mérite un effort.
Noëlle Adam (admirative)
Le 27/10/12 15:09, �g a écrit :
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.
Pas mal, en effet :). Les écolos éteindront le disque qui contient les
0, pour sauver la planète qui penche déjà salement d'un coté.
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 c'est vérifiable : en effet, les fichiers situés dans les secteurs
périphériques sont plus fragmentés que les autres. Le milieu du disque
est rempli en priorité, par le système installé d'abord. Le noyau au
milieu, pas de pépins.
Et ça bouchonne sur le périphérique, personne ne peut nier ça.
Et si vous ne croyez pas celle-la, je peux toujours réfléchir à une
autre, plus * énorme *.
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.
Pas mal, en effet :). Les écolos éteindront le disque qui contient les 0, pour sauver la planète qui penche déjà salement d'un coté.
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 c'est vérifiable : en effet, les fichiers situés dans les secteurs périphériques sont plus fragmentés que les autres. Le milieu du disque est rempli en priorité, par le système installé d'abord. Le noyau au milieu, pas de pépins. Et ça bouchonne sur le périphérique, personne ne peut nier ça.
Et si vous ne croyez pas celle-la, je peux toujours réfléchir à une autre, plus * énorme *.
Ç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.
pareil sur un SSD je suppose. alors pourquoi ne défragmente-t-on pas un SSD ? (hormis pour des considérations d'usure des cellules).
"Olivier B." <olivier.2a@turlututu.free.fr> 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.
pareil sur un SSD je suppose.
alors pourquoi ne défragmente-t-on pas un SSD ?
(hormis pour des considérations d'usure des cellules).
Ç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.
pareil sur un SSD je suppose. alors pourquoi ne défragmente-t-on pas un SSD ? (hormis pour des considérations d'usure des cellules).
YouDontNeedToKnowButItsNoëlle
Le 27/10/12 16:41, Olivier B. a écrit :
En fait, je me demande surtout pourquoi windows ne ferait pas comme unix, on est sur que cet article est juste ?
Métro de retard ? Ce qui existe sur les autres OS finit par atterrir dans windows. Mais les changements profonds qui touchent le comportement de la gestion disque, c'est moins facile que de copier le look d'une interface utilisateur. C'est plus utile par contre.
Noëlle Adam
Le 27/10/12 16:41, Olivier B. a écrit :
En fait, je me demande surtout pourquoi windows ne ferait pas comme
unix, on est sur que cet article est juste ?
Métro de retard ? Ce qui existe sur les autres OS finit par atterrir
dans windows. Mais les changements profonds qui touchent le comportement
de la gestion disque, c'est moins facile que de copier le look d'une
interface utilisateur. C'est plus utile par contre.
En fait, je me demande surtout pourquoi windows ne ferait pas comme unix, on est sur que cet article est juste ?
Métro de retard ? Ce qui existe sur les autres OS finit par atterrir dans windows. Mais les changements profonds qui touchent le comportement de la gestion disque, c'est moins facile que de copier le look d'une interface utilisateur. C'est plus utile par contre.
Noëlle Adam
Erwan David
Olivier B. écrivait :
On Sat, 27 Oct 2012 14:39:34 +0200, "Alf92" wrote:
Ç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.
Il y a aussi des problèmes d'allocation.
Quand un programme demande de la mémoire, il demande un bloc contigu.
Imagine que tu aies sur toute ta méoire 1k utilisé, 1k libre, 1k utilisé, 1k libre etc...
La moitié de ta mémoire est libre, mais si un programme demande 2k, ce n'est pas possible.
Le problème arrive peu sur les PC, qui ont une couche de virtualisation de la mémoire (MMU) et beaucoup d'espace. Pour un OS embarqué sur un système "petit" (pense à un terminal de paiement ou une carte à puces) c'est une problématique à prendre en compte.
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
Olivier B. <olivier.2a@turlututu.free.fr> écrivait :
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.
Il y a aussi des problèmes d'allocation.
Quand un programme demande de la mémoire, il demande un bloc contigu.
Imagine que tu aies sur toute ta méoire 1k utilisé, 1k libre, 1k
utilisé, 1k libre etc...
La moitié de ta mémoire est libre, mais si un programme demande 2k, ce
n'est pas possible.
Le problème arrive peu sur les PC, qui ont une couche de virtualisation
de la mémoire (MMU) et beaucoup d'espace. Pour un OS embarqué sur un
système "petit" (pense à un terminal de paiement ou une carte à puces)
c'est une problématique à prendre en compte.
--
Le travail n'est pas une bonne chose. Si ça l'était,
les riches l'auraient accaparé
Ç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.
Il y a aussi des problèmes d'allocation.
Quand un programme demande de la mémoire, il demande un bloc contigu.
Imagine que tu aies sur toute ta méoire 1k utilisé, 1k libre, 1k utilisé, 1k libre etc...
La moitié de ta mémoire est libre, mais si un programme demande 2k, ce n'est pas possible.
Le problème arrive peu sur les PC, qui ont une couche de virtualisation de la mémoire (MMU) et beaucoup d'espace. Pour un OS embarqué sur un système "petit" (pense à un terminal de paiement ou une carte à puces) c'est une problématique à prendre en compte.
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
Laszlo Lebrun
On 27.10.2012 16:59, YouDontNeedToKnowButItsNoëlle wrote:
Le 27/10/12 16:41, Olivier B. a écrit :
En fait, je me demande surtout pourquoi windows ne ferait pas comme unix, on est sur que cet article est juste ?
Métro de retard ? Ce qui existe sur les autres OS finit par atterrir dans windows. Mais les changements profonds qui touchent le comportement de la gestion disque, c'est moins facile que de copier le look d'une interface utilisateur. C'est plus utile par contre.
Noëlle Adam
Tiens t'as fini ton goûter? J'attends.
-- 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 16:59, YouDontNeedToKnowButItsNoëlle wrote:
Le 27/10/12 16:41, Olivier B. a écrit :
En fait, je me demande surtout pourquoi windows ne ferait pas comme
unix, on est sur que cet article est juste ?
Métro de retard ? Ce qui existe sur les autres OS finit par atterrir
dans windows. Mais les changements profonds qui touchent le comportement
de la gestion disque, c'est moins facile que de copier le look d'une
interface utilisateur. C'est plus utile par contre.
Noëlle Adam
Tiens t'as fini ton goûter?
J'attends.
--
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 16:59, YouDontNeedToKnowButItsNoëlle wrote:
Le 27/10/12 16:41, Olivier B. a écrit :
En fait, je me demande surtout pourquoi windows ne ferait pas comme unix, on est sur que cet article est juste ?
Métro de retard ? Ce qui existe sur les autres OS finit par atterrir dans windows. Mais les changements profonds qui touchent le comportement de la gestion disque, c'est moins facile que de copier le look d'une interface utilisateur. C'est plus utile par contre.
Noëlle Adam
Tiens t'as fini ton goûter? J'attends.
-- One computer and three operating systems, not the other way round. One wife and many hotels, not the other way round ! ;-)
spam.out
Alf92 wrote:
>> 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)
Les nouveaux alors, parce que je viens de mettre une barrette de 2 Go dans le mien.
Alf92 <alf921@gmail.com> wrote:
>> 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)
Les nouveaux alors, parce que je viens de mettre une barrette de 2 Go
dans le mien.
>> 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)
Les nouveaux alors, parce que je viens de mettre une barrette de 2 Go dans le mien.
abc abc
On 2012-10-27, Laszlo Lebrun wrote:
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.
Oui, completement idiot ces algos qui tentent d'eviter de fragmenter les fichiers. Par ce qu'il est bien connu que la fragmentation n'a jamais ralenti personne.
On 2012-10-27, Laszlo Lebrun <lazlo_lebrun@laszlomail.com> wrote:
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.
Oui, completement idiot ces algos qui tentent d'eviter de fragmenter les
fichiers. Par ce qu'il est bien connu que la fragmentation n'a jamais
ralenti personne.
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.
Oui, completement idiot ces algos qui tentent d'eviter de fragmenter les fichiers. Par ce qu'il est bien connu que la fragmentation n'a jamais ralenti personne.
£g
"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.
"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.
"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.
£g
"Alf92" a écrit dans le message de news: k6gsp2$uc6$
Ç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.
pareil sur un SSD je suppose. alors pourquoi ne défragmente-t-on pas un SSD ? (hormis pour des considérations d'usure des cellules).
Parce que, je suppose aussi, hein, le carnet d'adresses des données/secteur contenue sur le SSD est lui sur le DD central ou voir en ram et que si tu modifie l'adresse sur le SSD, le chat ne retrouve plus ses jeunes.
"Alf92" <alf921@gmail.com> a écrit dans le message de news:
k6gsp2$uc6$1@dont-email.me...
"Olivier B." <olivier.2a@turlututu.free.fr> 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.
pareil sur un SSD je suppose.
alors pourquoi ne défragmente-t-on pas un SSD ?
(hormis pour des considérations d'usure des cellules).
Parce que, je suppose aussi, hein, le carnet d'adresses des
données/secteur contenue sur le SSD est lui sur le DD central ou voir en
ram et que si tu modifie l'adresse sur le SSD, le chat ne retrouve plus
ses jeunes.
Ç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.
pareil sur un SSD je suppose. alors pourquoi ne défragmente-t-on pas un SSD ? (hormis pour des considérations d'usure des cellules).
Parce que, je suppose aussi, hein, le carnet d'adresses des données/secteur contenue sur le SSD est lui sur le DD central ou voir en ram et que si tu modifie l'adresse sur le SSD, le chat ne retrouve plus ses jeunes.
YouDontNeedToKnowButItsNoëlle
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. 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.
Noëlle Adam
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.
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.
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. 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.
