Reprise du message précédent :

 
oui, c ce que je que je veux dire

 
l'OS il requiert les données dont on a besoin + un supplément par anticipation, le firmware lui il peut cacher ce qui a transité sous la tête, ce sont deux choses différentes, et plus le disque sera défragmenté plus elles seront en accord... (y'a deux fonctionnement pour un cache: stoquer ce qui c'est passer avant, et continuer à stoquer par anticipation. c'est pareil pour les caches cpu, on ignore toujours le fait que le cache est autonome)
 
avec le cache, pendant que les données sont envoyées sur le bus IDE, le firmware peut continuer à lire sur le disque et stoquer dans le cache, et il est possible que les reqûetes futures (après que le transfert en cours soit terminé) tapent dans ce qui a été préchargé par le firmware.
 
en toute logique plus le disque sera mécaniquement performant, plus ce qui sera prechargé par le firmware sera important donc remplira plus le cache.

ouf, 20eme version d'une explication ; j'espère que celle-c sera plus convaincante parce que là perso je suis à cours

1) Je suis d'accord avec l'argument qui consiste à dire que si le disque lit physiquement plus vite qu'il n'émet sur la nappe, le cache c'est utile, au moins pendant les 8 premiers Mo.
Mais je crois que ça n'est jamais le cas : on lit physiquement à 50Mo/s et on émet sur la nappe à 133Mo/s.
2) Pourquoi ce qui a transité sous la tête et qui n'aurait pas été demandé par l'OS serait utile ? Si c'est vraisemblablement utile, alors l'OS l'aura vraisemblablement aussi le demandé. Ca ne prendra certainement pas plus de temps puisque de toute façon là le facteur limitant c'est bien de lire les secteurs, qu'ils aient été demandés ou non. Le disque n'aurait pas le temps de lire quoique ce soit d'autre et de le mettre dans le cache vu qu'il est déjà en train d'essayer d'émettre à 50Mo/s les données qu'on lui demande.
3) Est-ce que tu es en train de dire que pendant que le disque t'envoie des secteurs contigus à 50Mo/s, en fait il pourrait en lire beaucoup plus mais comme tu ne les lui demandes pas il se contente de les mettre dans son cache ? J'ai des doutes, mais ne suis pas expert. Ca, effectivement ça répondrai définitivement à ce topic.

Comme je voudrais bien comprendre, reprenons :
1) l'OS fait une requête d'une grosse série de secteurs de telle sorte que les lire ne nécessite aucune latence (pas besoin de déplacer les têtes).
2) le disque les lit physiquement et les émet sur la nappe IDE à sa vitesse maximale de 50Mo/s
 
Hypothèse A = le contrôleur/DSP qui lit les données ne sait pas traiter plus de 50Mo/s qui lui arrivent des têtes de lecture. Comme il n'y a aucun temps mort (déplacement des têtes), il n'y a aucune occasion pour le cache de stocker autre chose que ce qui est demandé par l'OS (qui mettra lui-même ces données dans son propre cache, court-circuitant celui du disque). Le cache ne sert à rien dans ce cas.
Hypothèse B = le contrôleur sait en fait traiter beaucoup plus de données, mettons à 100 Mo/s. Il en profite pour lire des secteurs non-demandés au passage (par exemple sur le plateau du dessous) et les mets dans le cache. Mais alors pourquoi dans ce cas ne pas réarranger la numérotation des secteurs pour que le secteur du dessous soit le suivant, ce qui permettrait dans le cas idéal de lire à 100Mo/s au lieu de 50Mo/s (et qui nous ramènerait au cas précédent) ?

Je suis content d'etre tombé sur ce topic juste avant de clicker sur "validation de la commande"    
J'allais prendre un 180gxp 120go avec 8mo de cache.
Comme un benet (bien que dans mes cours de cette année on etudie justement les algos d'acces disques et memoire, on survole devrais je dire) j'ai été attiré par 8mo de cache. La difference de prix par rapport aux perfs semble pas trop justifiée jusqu'a ce que je lise que pour ~10? on a 3 ans de garantie au lieu de 1.
 
Franchement cette histoire de garantie fait que je vais pas me prendre la tête plus longtemps sur lequel prendre.
IBM a aussi du vouloir qu'on évite de ce prendre la tête, car bien que theoriquement le cache superieur puisse agrandir la durée de vie en reduisant des mouvements de tete inutiles etc, ça m'etonnerais que dans la pratique ça améliore tant que ça la durée de vie.  
 
et un 180gxp 120go 8mo de cache, un    
Click  

Un comparatif sur des maxtor 2 et 8mo avec sou sans raid : http://www.madshrimps.be/?action=g [...] articID=69

Merci.
"Loading map BR-Anubis in UT2003"
2Mo/no RAID : first time 10s45, next time 6s36
8Mo/no RAID: first time 9s31, next time 5s56
Donc effectivement un disque avec 8Mo de cache va plus vite. Là je ne comprends vraiment pas.
Pour la version "next time", admettons que l'OS gère son cache n'importe comment. Mais pour le
"first time", je ne comprends pas, par définition les données n'ont jamais été lues, donc ne sont dans aucun cache, pas même celui du disque.
??

ça vient peut etre du fait qu'il lit des fichiers de configs pour l'agancement de la map en memoire par exemple.
Ce genre de trucs peut etre quoi.

Glacote, d'apres ton argumentation les 8 Mo de cache sur le disque ne servent à rien MAIS le seul probleme c'est que tu te trompe au niveau du fonctionnement du cache de l'OS.
Effectivement le cache de l'OS ne marche pas sur les secteur mais sur les fichiers.
 
Prenons un exemple:
- Tu veux lire le fichier toto.doc qui se trouve aux secteur 42100,42101 et 42102
- L'OS regarde dans son cache s'il a ce fichier: Il se trouve que non --> Lecture Disque
- Le disque regarde dans son cache si les secteur 42100,42101 et 42102 sont en cache, il se trouve que non -> Il deplace les bras et se place a bon endroit
- Il lit les secteur 42100,42101 et 42102 et les envoie à l'OS.
- Mais il s'arrete pas en si bon chemin puiske le bras et déjà placer et que souvent on fait des acces à des secteur contigue il lit les secteur 42103-42104..42120 et les place dans le cache
 
- Tu veux maintenant lire le fichier titi.xls qui se trouve en 42107-42108
- L'OS regarde s'il a ce fichier en cache : Non -> lecture disque
- Le disque regarde s'il a ces fichier en cache : Oui -> transfere les secteur.

Précisément pas : pourquoi la gestion du cache de l'OS serait-elle tellement moins performante que celle du contrôleur intégré au disque ? En l'occurence le noyau Linux a un buffer-cache qui fait précisément ça. S'il ne le faisait pas, c'est tellement évident qu'il gagnerait des perfs à le faire que tu penses bien queles hackers du noyau Linux y auraient pensé depuis longtemps.
Idem pour Microsoft à mon avis. Donc je maintiens que ce n'est certainement pas parce que l'algo du gestionnaire de cache intégré au disque est meilleur que celui de l'OS que le cache est utile.
EDIT: désolé pour le style agressif. Merci de tes remarques.

Pour Linux je sais pas mais pour les OS Microsoft je suis sur que le cache marche sur les fichiers et non pas sur les secteurs.

ce n'est pas que l'un est l'autre.
 
c'est que les deux méthodes se complémentent.

 
  Il en doute encore !

C'est bien d'en rire; mais le sujet du topic, c'est de comprendre pourquoi. Si tu as une explication, je suis preneur. Explique-moi donc pourquoi mon argument (à savoir que le cache de l'OS fait tout le bouleau mieux que le disque) n'est pas valable, et je clorais le topic.
Merci ...
EDIT: au passage ce qui te paraît à toi complètement évident, il y a des chercheurs en système pour qui c'est tout simplement faux. Donc halte à l'arrogance svp ...

Ta remarque remet en cause le concept de buffer et de mémoire cache non seulement dans l'informatique mais aussi dans l'industrie !
 
Alors ta pseudo-recherche scientifique...
 
Différence entre le cache OS et le cache du DD : y'en a un qui doit être géré par soft (donc qui prend du temps), et l'autre qui est transparent tout simplement.
 
Le cache OS et le cache disque n'interviennent pas au MEME niveau de toutes façons. On ne peut pas les comparer, ils sont complémentaires.
 
Si pour toi c'est pas suffisant...

1) "pseudo-recherche scientifique"
Tu as lu l'article ?
2) "ca prend du temps"
Le coût à choisir quelles données prefectcher, c'est du même ordre que le gestionnaire de mémoire virtuelle, soit quelques centaines de cycles par seconde. Sur un Athlon 2000+,
c'est complètement imperceptible. Merci de quantifier tes remarques.
3) Oui, ils n'interviennent pas au même niveau : le disque ne voit que des secteurs, alors que l'OS voit des secteurs et des fichiers. Encore une fois, l'OS a un cache et pour les secteurs (buffer cache) et pour les fichiers (page cache), et même encore un cache au niveau du système de fichier (pour bufferiser le contenu des répertoires, les inoeuds les plus couramment utilisés, etc.). Donc l'OS a beaucoup plus d'information (et en particulier au moins la même information), il calcule beaucoup plus vite, il a beaucoup plus de RAM et elle va beaucoup plus vite, et pourtant toi tu trouves normal que le cache du disque soit plus efficace. Moi pas, c'est tout.

 
Je te dis que le deux ne sont pas comparables, et toi tu continues à les comparer...
 
Le cache disque permet au cache OS d'être bien plus rapide. Et entre un système "hard" ultra simple et un soft qui dépend de bcp de paramètres à la fois, dont surtout la compétence du programmeur...

1) > "Je te dis que le deux ne sont pas comparables, et toi tu continues à les comparer..."  
C'est parce que c'est le sujet de mon topic, voilà tout.
2) > "Le cache disque permet au cache OS d'être bien plus rapide"
??
Le cache disque sert à faire en sorte que si fait deux requêtes séparées pour deux données contigues, la deuxième donnée est donnée tout de suite parce qu'elle a été astucieusement mise en cache par le disque lors du premier accès. Mais vu que l'OS ne fait que des grosses requêtes de plein de blocs contigus (pour remplir son propre cache) ...
3) "un soft qui dépend de bcp de paramètres à la fois"
bah s'il y a plus de paramètres que le disque, c'est qu'ils sont utiles, sinon on ne s'en servirait pas. Et encore une fois il y a plusieurs étages de cache ... à quels paramètres fais-tu allusion ?
4) "dont surtout la compétence du programmeur"
je pense que

(fs/buffer.c)
sont des programmeurs compétents, mais peut-être pas assez à ton goût ...
 
EDIT: pour info mon argument de base c'était : donne-moi ton algo hyper-simple et hyper rapide du contrôleur intégré au disque, et implémente-le directement dans l'OS en utilisant 300Mo de RAM. Je voudrais bien savoir par quel miracle ça pourrait ne pas être infiniment plus performant.

j'vous ais dis... si vous voulez savoir si sa vas + vite avec ou sans full cache disque, prenez une carte du genre Adaptec débile et mettez lui une barette de 128Mb au cul...

un ptit truc pas trop mal:
 
http://etd-submit.etsu.edu/etd/the [...] -final.pdf
 
en fait, pour justifier pourquoi le cache disque est complémentaire au cache OS, c'est simple, l'OS travaillant en LBA, ne connais pas forcément la position effective réelle du peigne de têtes, alors que le firmware lui le sait, et lors d'un cumul d'écritures, le firmware peut stoquer toutes les requetes en cache (et dire OK écriture finie à l'OS), et réorganiser les ordres d'écritures afin de minimizer les mouvements de têtes (seeks).
 
en fait il y'a moyen d'appliquer des optimisations coté OS, et d'autres coté firmware, chaqune étant complémentaire.

Merci pour ces précisions. Donc il semblerait que l'argument final soit:
"l'OS n'a pas accès à l'agencement physique des secteurs, qui est très différent de l'agencement logique. Donc il ne peut pas optimiser correctement les accès alors que le contrôleur intégré le peut".
J'en suis très surpris (quel intérêt à présenter une numérotation qui ne reflète pas l'agencement physique ? le seul intérêt devrait être de choisir une numérotation qui minimise la rotational latency entre deux secteurs de numéros consécutifs, sinon aucun logiciel ne pourra jamais espérer agencer ses requêtes intelligemment). Mais bon, si c'est vrai ...

tu parles d'un topic ! 7 pages pour savoir si le cache du DD est nécessaire ...

non, 7 pages pour comprendre pourquoi il est nécessaire

 
quelques infos à propos de l'adressage d'un disque dur aident à comprendre :  
http://www.bellamyjc.net/fr/theori [...] Interfaces

->karim63: comme tu le verras les 8 meg de cache n'augmente pas la fiabilité du DD, en tout quand on voit les stat de LDLC qui montrent qu'il y a plus de pannes sur les 8 meg.
 
Moi je pensais que le généralisations des 8 mega de cache était due au fait que la capacité des DD augmente énormément et que les perf diminuent plus on avance sur le plateau, donc avec les nouveaux plateaux gigantesques de 80 giga, il me semblait que les 8 meg faisaient buffer pour compenser (mais donc amélioreraient les perfs en début de plateaux par rapport à un 2 meg, et serviraient plutot à ce qu'elles se dégradent moins en fin de plateau).
Car ces 8 meg se sont généralisés à partir des plateaux de 60 giga, c'est peut être pas par hasard...

 
En effet ce n'est pas un hasard, arrivé à de telles capacités de disques, les gens finissent par remettre en question l'utilité d'avoir autant de Go ... Les constructeurs sont obligés de vendre en mettant en avant un nouveau critère !

 
Avant c'était les RPM, maintenant c'est le cache...

drapeau

J'ai recu un seagate 120Go 8Mo de cache de chez e-soph (c'etait une promo, ils etaient au meme prix que les 2Mo de cache alors bon...)
 
Finalement alors y'a une difference de perfs ou pas?

Sa doit, sinon ils s'ammuseraient po a en mettre autant!!!
Les PC avaient juste 640ko de mémoire avant vous vous rappelez...

 
Un peux si je me rappelle !!!

marketing quand tu nous tiens... ça serait pas la première fois qu'on te file un truc qui ne sert à rien ou ne se justifie pas pour l'utilisation que tu en fais

 
Justement, j'avais suivi que les 5 premieres pages du topic et c'etait pas encore tres clair sur le gain du cache 8Mo en pratique (genre comparer exactement les deux meme disques mais avec le cache different)

pour moi c'est clair : 8 Mo au lieu de 4 Mo celà apporte quelque chose mais je ne pense pas que celà soit très sensible... Mais tu as raison c'est ce genre de tests qu'il faudra avoir pour en être sûr.

 
Enfin j'ai eu mon seagate 8Mo au prix du 2Mo donc tfacon y'a rien de perdu

Bon, après de longues recherches j'ai trouvé ça:

Ca permet de choisir la taille du tampon de l'OS à affecter à chaque périphérique.
La valeur maximale est 255, et par défaut c'est 120 chez moi.
Reste à savoir pourquoi on ne peut pas mettre plus que 255 ...

sinon pour avoir un camparo 2mo/8mo pour le même drive:
 
le JB c'est le 8Mo, le BB le 2Mo.
 
http://www.storagereview.com/php/b [...] 9&devCnt=2