Reprise du message précédent :

Exact, autant pour moi.

 
1# les secteurs c'est physique sur le disque
 
2# les clusters sont attribués lors du formatage et leur taille dépend du système de fichier utilisé.
 
3# ni l'OS ni le disque ne mettent en cache l'un ou l'autre. Ils travaillent avec des octets qui sont stockés sur les clusters disposés sur les secteurs du disque dur.

Il y a un aspect important qui a été brièvement abordé : est-ce que le cache du disque ne sert qu'à stocker des données ou bien sert il aussi de zone de traitement ?
Imaginons qu'il serve de mémoire tampon pour un algo de compression. Peut être que plus de place permettrait de mieux compresser les données et d'optimiser le débit de l'interface.
(C'est juste une hypothèse )
 
Ou alors, le cache plus important permet de mieux regrouper les secteurs pouvant être écrits d'un bloc (en évitant au maximum les déplacements des têtes d'écriture)

Ou alors, le cache plus important permet de mieux regrouper les secteurs pouvant être écrits d'un bloc (en évitant au maximum les déplacements des têtes d'écriture) c'est que j'abordais précédemment

 
Bahh sous Windows 98 en tous cas c'Est...
 
[vcache]
Chunksize=512
MinFilecache=131072
MaxFilecache=131072
 

 
merci

Bah OK, mais normalement c'est le tampon de l'OS qui se débrouille pour ne faire que des requêtes portant sur des gros paquets de blocs contigus. Auquel cas le cache ne sert, encore une fois, à rien.

Bon, est-ce que quelqu'un sait comment désactiver le cache disque intégré à un disque dur, pour en avoir le coeur net ?
Réponse souhaitée avec un clef de la base de registre Win32 ou avec un paramètre de hdparm, merci d'avance ...
EDIT:
démarrer, faire hdparm -A 0 /dev/hda
puis stresser un peu le système. Observez-vous une différence ?
PS: là je suis sur une machine en SCSI donc je ne peux pas tester
(/dev/sdb: operation not supported on SCSI disks)

c quoi cette commande ? existe pas sous XP

 
C'est normal, c'est sous linux

je m'en doutais ; c'est l'allusion à Win32 au-dessus qui m'a fait poser la question tout de même.

/dev/hda, on a pas l'habitude de ce genre de notation avec windows  
 
C'est quoi la différence avec /dev/sdb

 
je pense hda = hard drive a
sdb scsi disk b

 
ah que j'aimerais savoir manier linux/unix correctement!

Donc dans les hda, hdb ... , il n'y aurait pas les disques SCSI

 
je pense, effectivement

Bon, désolé d'avoir été un peu lapidaire.
Effectivement, hdparm est une commande Linux et effectivement,
/dev/hda désigne le premier disque dur ide (en général le disque système).
Ma question s'adresse donc aux Linux-men : voyez-vous une différence sensible entre hdparm -A 0 /dev/hda et hdparm -A 1 /dev/hda ?
Quant à Win32, si quelqu'un connait un soft pour désactiver le cache du disque dur (pas celui de l'OS !), je suis preneur.

Bahh cassez vous pas la tète! Si il est la, c'est que c'est mieux qu'il soye la! Puis pour l'utilitée des cache a 8Mb contre 2Mb, bahh les i486 n'avaient pas 512Mb de Ram!
 
 

Attention, le débit entre le HD et la CM est bien limitée par la nappe.  (et bien sur par le pont PCI/ATAPI mais là ce n'est plus un problème de physique)
Pourquoi est-ton passé d'une nappe 40 points à une 80 points?
Tout simplement parce que la 80 points est blindée. (1 points / 2 est la masse)
Est pour quelle raison?
Et bien a cause du bruit qu'engendre des modulations HF. (133Mo/s => 16.625 Mbits/s soit env 16Mhz pour la fondamentale; bref une modulation genre Onde courte)
Si vous dépassez cette fréquence, la nappe devient poreuse électriquement; son impédance complexe change, ce qui perturbe le pont PCI/ATAPI.
D'ou un risque d'erreur ou de perte de données.

TEST password

Il faut différencier deux caches: le cache du disque dans l'OS et celui du disque . Celui de l'os sert en lecture,celui du disque en écriture. En effet lorsque l'on écrit sur le disque il fallait avant l'existence dec cache,déplacer les t^tes, attendre le délait rotationnel pour écrire sur le bon bloc,et attendre de savoir si l'opération s'était bien passée ,pour libérer l'interface. Avec le cache du disque on va écrire dans le cache,l'interface est libéré,et le controleur IDE peut alors lire ou  écrire à nouveau sans ettendre la fin réelle de l'opération.

+1 exactement    
 
Le cache du HD est la pour optimiser le fonctionnement du hard
Alors que le cache de l'OS est un cache 'soft' utiliser pour optimiser le fonctionnement de l'OS.
Tout les appareils moderne ( APN, telephone portable, carte a puce ) ont un peu de memoire ( RAM ).
Par exemple, les APN ont besoins de memoire pour stocker les photos avant de les ecrire physiquement sur la carte memoire ou pour travailler une photo ( rotation, zoom, ... )
 
Dans le cas des HD, le cache c'est un peu comme la RAM d'un OS, c'est de la memoire utilisée par le CPU et le fireware du disque pour son fonctionnement... donc plus y'a de RAM plus le firmware peut faire de chose et plus les perf seront proche du maximun supporté par le hard et par l'interface de transfert.
 
Le cache de l'OS n'est la 'que' pour eviter de faire appel trop souvent au systeme disque qui est tres lent par rapport aux autres composants du systeme.

 
OK OK tout le monde est d'accord, mais là n'est pas la question. Tu as le choix entre mettre un cache avant la nappe (intégré au disque) ou après la nappe (RAM).
La différence :
 - le cache intégré fait 8Mo, latence inconnue, débit < 133Mo/s
 - la RAM fait 300Mo, latence < 50ns, débit > 4Go/s
Chaque fois que le cache intégré au disque permet de renvoyer directement une donnée cachée ou de différer une écriture, le cache de l'OS pourrait faire aussi bien (en fait bien mieux du fait des performances supérieures de la RAM).
Pour s'en convaincre, il suffit de considérer l'algorithme utilisé par le gestionnaire du cache intégré au disque, et de l'implémenter dans la fonction de l'OS qui envoit les requêtes au disque. On transfère la charge de calcul du processeur (petit RISC) intégré au disque vers le CPU.
 
Donc s'il vous plaît cessez de dire que le cache intégré au disque permet d'améliorer les performances physiques du disque; tout le monde est d'accord sur ce point. La question est pourquoi faire à l'intérieur du disque quelque chose que l'OS ferait beaucoup mieux ?

le disque n'est pas en 10000 trs/min?

Même si le disque tournait à 100000tr/min, ça ne changerait rien au problème du cache. Par ailleurs, la rotational latency serait bien divisée par 10, mais toutes choses égales par ailleurs la latence de l'actuateur (qui déplace les têtes) resterait de l'ordre de 5ms. Donc la latence du disque resterait de l'ordre de 5ms.
Quant au débit, il serait au mieux multiplié par 10 (avec la nappe qui va bien ...), mais 500Mo/s <<  4Go/s ...
 
Enfin, il est bien entendu qu'un disque à 100,000 tr/min a furieusement tendance, du fait de la force centrifuge 100 fois plus élevée qu'à 10,000 tr/min, à exploser littéralement ...

glacote > tu n'as pas du lire ce que j'ai ecrit, le cache disque est necessaire pour que l'electronique qui gere ( entre autre ) les tetes de lecture fonctionne !!
 
Arreter de dire que le cache de l'OS suffit !! il n'a pas la meme fonction et de plus un cache géré pas un systeme aussi complexe qu'un OS ne sera jamais aussi performant que celui géré par un systeme embarqué dédié à une tache bien precise !
 
Les deux caches sont complemetaires, celui du disque est la pour que le disque puisse fonctionner et celui de l'OS n'est la que pour limiter au maximum les acces a un peripherique 'lent'.
 
En fait le terme de 'cache' pour parler de la memoire embarquée sur le disque n'est peut etre pas judicieux...
C'est vrai qu'elle est utilisée comme tampon entre l'electronique et l'interface de transfert, mais sont role n'est pas de stocker des données pour une utilisation future comme le fait le cache d'un OS. Son role principal est de faire fonctionner le disque tout simplement.
 
Comme ca été deja dit, le fait d'avoir beaucoup de cache ( 8Mo ) permet de reduire les temps de latence du a la sequencialité des acces a un disque dur. Il faut quand meme savoir qu'on ne peut pas avoir d'acces concurrents sur un HD :
Si 2 process veulent ecrire, il y en aura forcement un qui sera mis en attente... plus vite le disque reponds et plus vite process en attente sera réveillé.
 
Il vaut mieux stocker les données en attente 'le plus pres possible' de l'electronique et laisser a cette derniere le soin de géré ses priorités plutot que de demander a un OS, dont ce n'est pas le but, de la faire.
 
 
Pour conclure, et repondre a ta question :  
pourquoi faire à l'intérieur du disque quelque chose que l'OS ferait beaucoup mieux ?
 
on le fait a l'interieur du disque parce que justement c'est mieux fait que ce que peut faire un OS. Un OS c'est fait pour géré des processus pas le hardware d'un perif bien precis.

 
Tu as dit que le temps d'accès dépendait uniquement de la mécanique du DD, ça n'est pas vrai, ça dépend aussi de la réponse global du système (CM, contrôleur IDE, firmware du DD...)
.

Merci de ta réponse.
OK, autant pour moi le cache est indispensable au fonctionnement des têtes (il faut bufferiser tout un secteur avant de l'envoyer sur la nappe) ... mais 8Mo certainement pas (64ko ?)
OK pour l'argument du multi-threading, problème spécifique; mais je ne suis pas d'accord sur
[citation]
Si 2 process veulent ecrire, il y en aura forcement un qui sera mis en attente... [/citation]
si c'est vrai, alors OK, 8Mo c'est bien mieux. Mais pour autant que je sache, l'OS a un cache disque dans lequel il écrit tous les secteurs, pour tous les processus qui veulent écrire (en mode utilisateur), et lorsque ce tampon est plein, là il déclenche une unique écriture (là on entre en mode système) de tous les secteurs.
En particulier, lorsque deux processus veulent écrire (en mode utilisateur) sur le disque, en fait ils écrivent en mémoire (donc potentiellement "simultanément" ), sans que l'un doive attendre la fin de l'opération de l'autre. C'est la raison de l'appel à copy_from_user si je me souviens bien.
 
Je peux me tromper, mais si c'est juste, alors en plus de faire cache disque l'OS sérialise les accès, et on en revient à mon problème de départ : donne-moi l'algo intégré au disque dur, implémente-le dans le gestionnaire de cache de l'OS, et hop je prétends que tu multiplie énormément les performances.
Quant à savoir si ce calcul est fait plus efficacement par le disque ou par le CPU, c'est à voir : OK le contrôleur est un RISC, mais ton Athlon est un 2000+.
Dans tous les cas c'est le RISC qui va effectivement recopier/traiter les données
(le CPU déclenche juste un DMA), la question est donc de savoir si l'algorithme qui décide quelles données mettre en cache est exécuté plus efficacement par le RISC ou par le CPU. Je penche franchement pour ton Athlon 2000+, sans parler de l'évolutivité, mise-à-jour, améliorations, etc.
 
PS: comme je l'ai dit dans le premier post, ce raisonnement est vraisemblablement faux puisque les disques des gros serveurs de fichiers sous AIX/HP-UX ont malgré tout un gros cache intégré. Ma question est : quoi ?

Je pense à un truc : est-ce que l'OS est au courant du contenu du cache du disque. Ca m'étonnerais fortement  
On est manifestement dans le cas d'un cache inclusif avec celui géré par l'OS. Ca veut dire que ce qui est présent dans le cache du disque l'est aussi dans celui géré par l'OS, et donc que les accès en lecture au cache disque sont très rares (l'OS va directement dans le cache qu'il gère lui même).
 
Donc, je pense aussi qu'il sert avant tout pour le fonctionnement interne du disque  
Comme par exemple :
- bufferiser les écritures (en les regroupant pour minimiser les déplacements des têtes)
- attendre la disponibilité de l'interface (si la mécanique est lancée pour lire les données, avec les têtes bien placées, ce serait dommage de l'interrompre sous prétexte que l'interface n'est pas disponible )

OK.
Mais comme je l'ai déjà dit, après avoir lancé ma Mandrake 9.1, les disques finissent par s'arrêter même si j'ouvre une nouvelle fenêtre Mozilla/un nouveau document OpenOffice.
Les bibliothèques/artworks/etc nécessaires sont dans le cache de l'OS (jusqu'à 650 Mo) et il n'y a aucun accès disque. En d'autres termes avec un gros cache les accès de l'OS au disque sont rares, et il y a peu de chances que lorsque l'OS fait sa requête les têtes soient en cours de positionnement.

Quelques precisions sur l'utilité d'avoir 8Mo embarqués :
 
Dans le protocole ATA, il existe un mode burst qui permet de 'donner' toute la bande passante du canal, pour rappel il y a 2 canaux par controleur ( primaire et secondaire ), au disque pour qu'il vide son cache.  
Dans ce mode le disque vide son cache a la vitesse maximum supportée par l'interface ( du disque pas ATA ). La vitesse est donc optimale, et plus le cache est important plus la duree du mode burst est longue.
 
autre point, le cas ou il y a plusieurs disques ( deux ) sur le meme canal.
Chaque disque utilise le canal ATA a tour de role, donc pendant q'un disque transfert ou recoit des données, l'autre peut remplir son cache et le vider en mode burst des que le canal est libre.  
 
L'interet d'un cache important parait evident.
Ca peut expliquer aussi pourquoi les disques SCSI on un cache encore plus important ( 16Mo ) puisque on peut avoir 7 periph sur une chaine SCSI contre 2 par canal ATA.

l'intérêt du cache disque est :
- lecture en avance de demande (donc l'OS ne l'a pas encore en cache puisqu'il ne l'a pas encore demandé )
- écriture différée (le disque répond que l'écriture est ok alors qu'elle uniquement copiée dans le cache du disque). Ceci permet une meilleure gestion des entrées/sorties en multi-taches. En revanche je ne suis pas sur que l'interface IDE ne limite pas justement cet aspect des choses contrairement au disques SCSI...
- gestion et réorganisation des lectures/écritures à la volée (applicable surtout en SCSI).
- l'OS ne connait pas du tout la structure physique réelle du disque. Seul le firmware du disque la connait. Donc le cache disque permet de cacher plus efficacement puisque seul le disque sait réellement où la donnée va être écrite.
 
Pour moi, je ne pense pas que la différence entre 2 Mo et 8 Mo sera sensible en environnement mono-poste. En serveur multi-utilisateurs c'est autre chose...

Merci pour ces précisions.
Là je crois que je commence à comprendre : si on m'envoie 8Mo de données, je met tout dans mon cache (à 133Mo/s) et je les écrirait plus tard (à 50Mo/s). Au total ça va deux fois plus vite.
En revanche si on considère la copie d'un ficier de 4Go, l'OS va bufferiser (300Mo) puis enchaîner une série de requêtes en écriture de gros paquets >> 8Mo, donc à part au tout début le débit sera limité par le débit du disque, soit 50Mo/s. Au total, seul le cache de l'OS sera utile.
 
En revanche en lecture à mon avis ça ne change rien : si une application demande un morceau de fichier récemment accédé, l'OS l'a encore dans son propre cache et ne demande rien au disque.
Bien vue, la différence entre lecture et écriture ...

L'OS peut tout aussi bien choisir de lire en avance ou différer les écritures : vous souvenez-vous de smartdrive (et de "smartdrive /c" à faire avant de rebooter sous peine de pertes de données) ?
 
[citation]
- gestion et réorganisation des lectures/écritures à la volée (applicable surtout en SCSI).
- l'OS ne connait pas du tout la structure physique réelle du disque. Seul le firmware du disque la connait. Donc le cache disque permet de cacher plus efficacement puisque seul le disque sait réellement où la donnée va être écrite.
 
Pour moi, je ne pense pas que la différence entre 2 Mo et 8 Mo sera sensible en environnement mono-poste. En serveur multi-utilisateurs c'est autre chose...
[/citation]
L'OS suppose que des secteurs de numéros consécutifs sont contigus. Mais en effet il n'y a pas de raison que ce soit vrai; en particulier tous les disques gardent quelques secteurs en rab' pour se substituer à ceux défectueux (au niveau du formatage de bas niveau, pas du formatage d'une partition), auquel cas deux secteurs de numéros consécutifs peuvent être très éloignés. Mais dans le cas général, il me semble que deux secteurs consécutifs sont proches physiquement, non ?
 

zoli débat ...
mais je crois que le cache disque de l'os n'est pas utilisé pour une écriture sur le disque
Je veux bien admettre l'intéret du débat sur la lecture, en cas d'un disque en acces consultatif

 
oui et non, je crois, que les secteur sont organisé en tenant compte de la rotation du plateau.
 
il y a plusieurs cas
 
dans le cas d'un plateau et une face utilisee:
2 secteurs consécutifs sont séparés par un nombre de secteurs correspondant au deplacement du plateau pendant le temps de traitement de l'information lu.  
( je sais pas si je suis clair     )
 
En clair, l'organisation des secteurs sur le disque est faite de facon a ce que le secteur suivant soit sous la tete au moment ou celle ci peut le lire ( tps de traitement de la lecture precedente terminée )
 
plus d'un plateau ou face:
le secteur suivant est situe sous une autre tete sur une autre face et/ou plateau.
 
Bref ca doit pas etre simple de faire un soft de formatage  

Merci de ces précisions, effectivement je crois que c'est fait comme tu dis : si pendant le temps de traitement d'un secteur la tête de lecture passe au dessus de 10 secteurs, les secteurs sont numérotés
1 11 21 31 41 51 61 71 81 91 2 12 22 32 42 52 62 72 82 92 3 etc ...
 
Cela dit la seule conséquence en est que des secteurs de numéros consécutifs ne sont pas placés contigument mais peuvent bien être lus successivement sans latence additionnelle.

Je crois avoir vu quelque part qu'une sorte de convention indiquait que les premières pistes devaient être à l'extérieur du disque (là où c'est le plus performant).
Mais ca n'empêche pas les secteurs de ne pas être consécutifs

pour les acces a un disque :  
 
on a :
 
-le cache de l'OS (quand il en a un...)
il copie ce qui a déja été lu/écrit.
il est rapide (selon la ram) et temps d'acces bas (selon la ram aussi)-> sous un système i875p : 6400Mo/sec et 5ns de temps d'acces en théorie.
les problèmes : windows écrit d'abord en cache, puis ecrit sur le média ce qu'il y a dans la cache, ce qui a pour effet, si il y a une panne de courant, que ce qui est en cache disque et pas encore écrit est perdu. c'est pour ca que les clefs usb ont le cache de l'os désactivé sous XP, pour qu'on puisse les enlever sans problèmes de pertes de données (ca arrive parfois sous 2k)
 
-la cache disque : il est en général de 2 ou 8Mo (parfois plus, sur les portables/serveurs)
rapide : selon l'interface IDE (133Mo/sec en PATA, 150 Mo/sec en SATA, jusque 320 Mo/sec en SCSI)
temps d'acces assez court : l'IDE tournant à 16Mhz, on obtient 62ns de temps d'acces.
le cache disque lit ce qu'on demande + un peu apres. et il se remplit, apres un certain temps, et garde ce qui est souvent demandé, réorganise, etc. en gros comme un cache l2 de CPU.
 
-le disque : il est lent (jusque 60 Mo/sec en gros) et a un temps d'acces assez lent (environ 10ms) (ca dépênd du disque, 4200/5400/7200/10000/15000 rpm)
 
 
scénario normal : l'OS demande la donnée X
 
cas A : la donnée est en cache ram, on la prend : tres rapide
cas B : la donnée est en cache disque, on la copie en cache ram, on la prend : rapide
cas C : la donnée est sur le disque, le disque la copie ainsi que X+1 en cache disque, on la copie en cache ram, on la prend : plutot lent.
 
maintenant, on redemande X : si le temps entre les 2 demandes est court, on passe par le cas A directement, sinon, on recommence.
 
si on demande X+1  : si on le demande apres, il y a des chances que X+1 soit sur le cache disque, donc ca va + vite. + le cache disque est grand, + il y a de chance que X+1 (+2+3+4 etc.) y soit. donc on gagne du temps. et en informatique, apres une donnée X, on demande souvent X+1, statistiquement, donc avec 8Mo de cache, on gagne du temps en général.
 
 
pourquoi ne pas mettre 16 ou 32 Mo de cache, alors ?
 
on le fait dans les portables : ca empeche le disque, + lent au départ de mouliner sans arret et de chauffer et consommer.
on le fait dans les serveurs : ca accélère le système car on demande bcp + souvent les même données en cas d'utilisation serveur.
 
pourquoi pas dans un dekstop ? pour le prix, et puis ca sert pas a grand chose, on demande rarement des données continues en boucle (a part en cas de traitement vidéo et autres cas particulier) et puis on doit remplir et vider ce cache de temps en temps (quand on change de programme, par exemple) ce qui peut etre pénalisant si le cache est gros.  
 
 
 
 
 
 
 
 
 
 

je crois tout de même qu'il ne faut pas confondre 2 choses :
 
- le cache de l'OS s'occupe d'accélérer les données entre les processus et les données applicatifs
 
- le cache du disque s'occupe d'accélerer les données entre la surface du disque et l'OS
 
Si l'on n'a pas de cache disque, la première lecture demandée par l'OS quelque soit sa technologie (n'oublions pas que l'OS a un haut niveau d'abstraction des données, donc se situe loin du hardware) sera plus lente que si le disque dispose d'un cache efficace... ?

La toute première lecture, elle se fait depuis la surface du disque, quels que soient les caches disponibles