Reprise du message précédent :

 
franchement c casse-guele...enfin moi je tenterai pas...
vaudrait mieux acheter un dur neuf faire ton backup et le ramaner sous 8 jours pour te faire rembourser

 
   
 
j'v essayer d'en trouver un gros a preter
si je trouve pas d'autre moyen

au sujet du raid0
 
j'ai 2*200go donc
 
serait il preferable de partitionner les 400gig?

bhen rien que pour une question d'organisation oui...

Question rapidité c mieux?

pas d'impact flagrant a mon avis, par contre nivo defragementation, si tu fais des partitions tu foutras moins vite le bordel.  
 
mais c a confirmet car je sui pas hyper certain de ce que j'avance.

Native Command Queuing et Tagged Command Queuing il me semblais que c'était pas exactement pareil
 
Car logiquement les 180GXP et 7K250 font du TCQ (c'est leur electronique qui le gere...)
Donc pour moi le TCQ c'est l'HDD qui le fait, et le NCQ c'est le controleur qui s'arrange avec l'HDD (d'où le fait que ca doit etre plus efficace donc).
 
Apres c'est etrange comment ce sujet est tres flou

bah en fait le TCQ c'est la réorganisation de 256 commandes maxi en files d'attente selon l'emplacement des têtes
et le NCQ benh pareil avec 32commandes maxi
 
En fait le contrôlleur prend normalement en compte cette options du DD, il peu aussi la désactivé dans son bios, dans le NCQ pour l'instant c'est activé par défaut sur le DD comme sur le TCQ des IBM/Hitachi
 
Le TCQ IBM/Hitachi semble effectivement gérer uniquement par le contrôlleur DD, ce qui n'est pas le cas du TCQ SCSI et NCQ qui sont gérer au niveau Interface  
 
A priori c'est juste une version light comparrer au TCQ du SCSI d'aprés la doc officiel de segeate :
http://www.seagate.com/docs/pdf/ne [...] o-sata.pdf
 
et la doc de Tom's hardware:
http://www.tomshardware.fr/article [...] &NumPage=2

Donc en gros, on sais pkoi les 7K250 sont les HDD ATA/SATA les plus performant, car leur TCQ marche TOUT le temps, et pas seulement au bon vouloir du controleur SATA, comme celui des Seagate 7200.7 (qui par ailleurs sont seulement NCQ depuis tres peu, et pas encore dispo pour la grand distribution).
 
Pareil, le WDC Raptor utilise le TCQ et pas le NCQ... Mais il necessite un controleur adapté... Ce qui fait que comme actuellement ce sont que les Silicon Image qui supporte les NCQ/TCQ (je sais pas si c'est l'un ou l'autre ou les deux en fait car Silicon Image ne documente pas trop) et que c'est avec des drivers pas dispo au DL ...
 
Finallement, les TCQ/NCQ seront vraiment utile des le SATA II je pense... mais actuellement c'est dur d'en profiter, et surtout d'etre sur d'en profiter... Faudrai que les BIOS ecrive si le NCQ est on ou pas par exemple je pense..
 
Enfin, je crois que quand meme les carte RAID SATA a base de Silicon Image actuelles doivent etre NCQ/TCQ ... apres là, faudrai se documenter.

Drapal
 
Je compte faire un RAID IDE avec 2 Seagate 7200.7 8Mo de cache ATA, sur le controlleur SATA de ma CM (Asus A7N8X-E Deluxe).
 
Je posterai des benchs une fois le matos reçu

Merci pour ces précisions. Mais j'ai une question simple: à quoi ça sert ? Croyez-vous qu'il existe un seul OS assez benêt pour ne pas réorganiser lui-même les requêtes qu'il adresse au disque dur ?
Un indice ce trouve sur cette page ...
Bref c'est comme le cache 8Mo, ça ne sert à rien ...
PS: oui je sais on n'es pas vendredi ...

   
 
C'est une réorganisation à la volée selon l'emplacement des têtes des disques !
20 à 40% de perfs en plus en cas de grosse tâches d'écriture !
c'est une optimisation impossible en soft !
Et le cache 8mo, bien sûr ça sert à rien ! mais fait pas une généralité de ton cas, en SATA c'est obligatoire avec un transfert série
Pour l'IDE, seulement en ATA100/133 et pour certaines tâches
En SCSI ça joue beaucoup.

Personne n'a essayé du RAID IDE sur controlleur SATA ?
 
Y'a-t-il des subtilités ?
Des trucs à savoir avant ?
 

J'aimerais que tu m'expliques pourquoi: celui qui donne l'ordre d'écriture, c'est l'OS. Dans le cas du noyau 2.6, les requêtes sont maintenus dans l'ordre, donc elles arrivent au disque dans l'ordre. Donc je ne vois pas bien ce que le contrôleur(southbridge ou intégré au disque) va pouvoir réordonner ...

mais non pas le contrôlleur de port southbridge !
c'est essenciellement une prise en charge de cette technologie contenu dans le disque dur au niveau de l'interface pour qu'elle soit activé.
aprés en SCSI et en sata une gérance de chaque cache au niveau de l'interface lorsqu'il y a plusieurs DD (surtout pour le Raid) mais là c'est plus complexe et surrement pour des echanges entre DD sur le bus SCSI
 
c'est essenciellement du fonctionnement interne au disque, croit tu que l'OS sait ou se trouve les têtes à X moment ? du tout si ça fonctionné ainsi, ça boufferait plein de bande passante de l'interface en echange entre OS et contrôleur DD.
 
Le NCQ et TCQ est indépendant des OS et de leur systéme de fichier. ça fonctionne sur tout OS.  
 
La réorganisation se situe au niveau du cache DD, les infos sont transmises au cache dans l'ordre optimisé pour l'execution OS, tel fichier avant tel fichier
mais pas dans l'ordre de la tâche à accomplir, d'écriture ou lecture en fonction de l'emplacement des têtes et de l'emplacement physique des clusters à lire. Les fichiers peuvent êtres contenu dans plusieurs clusters réparti sur la surface du disque (fragmentation)  
 
En gros si la têtes se situe au milieu du plateaux et qu'à cette endroit les données écrite ou a écrire font partie de la requête suivante, le dd va exécuté la requête suivante au lieu de celle en cour qui se situe en début de disque par exemple
 
ça évite au têtes de faires des allé retour pour rien.
Et là aussi tu peu deviner l'importance que prend la taille du cache DD surtout en SCSI ou 255 requêtes peuvent êtres envoyées simultanément.
 
sérieux c'est une technologie incontestable vis à vis du gain, et ça fait perpette que ça existe en SCSI
 
Pour évoquer la technologie par une image :
une fourchette se trouve dans la cuisine, une clef dans le hall d'entrée.
tu est dans le salon, pour accéder à la cuisine tu est obligé de passer par le hall d'entrée et de ressortir par l'accés cuisine/salon (en admettant par exemple que tu soit exactement à la porte d'accés hall/salon).
ta mère demande d'aller chercher dans l'ordre la fourchette puis la clef
en passant dans le hall tu va prendre la clef avant d'entrer dans la cuisine pour prendre la fourchette, si non tu fait un allée/retour inutile entre la cuisine et le hall et tu serait un bel abruti !
 
Un exemple bien que la capacité des disques actuel le rendent un peu obsolète :  
test un disque SCSI rempli à 95% de 7200tr/min et un identique en perfs et caractéristique en IDE, pareil rempli à 95%, la différence de perfs va êtres flagrante même en lecture, l'IDE va mouliné à fond

+1
Bien sur que si que le cache sert en ATA... Pour avoir une meilleure constance du debit en ecriture essentiellement, mais pas que pour ça...
 
De plus, tellement les 8Mo de cache servent à rien, Seagate proposera 16Mo de cache dans ses 7200.8

De plus le liens fourni par glacote pour l'optimisation I/O concerne les opérations multiple de lecture/écriture en file d'attente
 
- Les opérations de lectures s'opére ponctuellement et sont généralement trés nombreuses.
- Les opérations d'écriture sont longue.
 
Lorsqu'on lit et écrit pendant un laps de temps important, les opérations d'écriture viennent s'intercaler entre les opérations de lecture ce qui les ralenti et donne des temps mort
Le passage du mode écriture à lecture puis écriture  multipli les déplacement des têtes pour une opérations de lecture minimal
 
l'optimisation cité consiste à mettre en attente les opérations d'écriture lorsqu'une lecture vient d'être éxécuté et qu'une opération de lecture éventuelle se trouverai aprés l'opération d'écriture qui suit la premier lecture
L'opération de lecture suivante seras éxécuter au lieu d'éxécuter l'écriture qui aurait dû suivre normalement.
 
En gros ça permet de créer des regroupement partiels de commandes selon leur type de tâche, écriture ou lecture
 
ça optimise le temps d'éxécution et réduit un peu les déplacements des têtes vis à vis de la lecture de la table d'allocation du systéme de fichier lors de l'opération de lecture. mais ajoute aussi des temps mort (enfin qui permette l'optimisation)
 
Bref ça n'a pas grand chose à voir avec l'optimisation du TCQ/NCQ.

OK très bien, j'avais cru comprendre ça dans l'explication sur les différences entre Native Command Queueing et Tagged Command Queuing.
Mais peu importe pour moi, mon argument reste strictement le même.
 
 

Je ne suis complètement pas d'accord avec toi. C'est exactement la même raison que celle pour laquelle le cache intégré ne sert à rien (passé 2Mo). Je prétends que bien au contraire l'OS "sait" comment sont agencés les secteurs: ils sont agencés de telle sorte que quand le bras, le DSP, le contrôleur ont fini d'envoyé le secteur n sur la nappe, ils sont prêts à envoyer le secteur n+1 sur la nappe sans aucune délai (NB: ce qui ne veut pas dire que les secteurs n et n+1 soient consécutifs sur le plateau, ils sont espacés pour tenir compte du temps de traitement). Je mets tous les lecteurs de HFR au défi de me trouver un seul contre-exemple. Cette hypothèse est fait par tous les OS, tous les logiciels, tous les moteurs de base de données depuis pratiquement que le disque dur existe. Pourquoi un constructeur choisirait-il un autre agencement (sachant que ça ne change strictement rien au reste du disque dur, ça n'influence ni la mécanique ni le DSP ni rien du tout, c'est purement une question de convention). C'est comme les standards pour les protocoles réseau, si un jour un disque choisit un autre agencement ses performances vont être épouvantables avec la plupart des logiciels.
Bref l'argument du "seul le disque sait comment réorganiser au mieux les requêtes" est, à mon sens, nul et non avenu.
 

Je suis tout-à-fait d'accord avec toi là-dessus. Note que l'ordonnancement des bio n'a lui non plus rien à voir avec le système de fichier, le fait qu'il y ait du RAID5 de crypt de RAID0 de JBOD par-dessus, peu lui importe. Il voit juste des listes de secteurs à lire/écrire, et les envoie systématiquement triés et regroupés.
Que crois-tu qu'il faille faire de plus ?
 

Non. Là il y a le problème des performances intrinsèques de l'IDE.
En revanche considérons les scenarii suivants:
 scenario A = écris les secteurs 101, 102, 103, etc.
 scenario B = écris les secteurs 101, 201, 102, 202, etc.
 
Le NTQ va réorganiser les requêtes du scenario B en
"écris les secteurs 101, 102, ..., 201, 202, ...".
C'est le principe, formidable.
 
Maintenant moi je dis que de toute façon les requêtes qui seront envoyées par le noyau 2.6 seront déjà dans l'ordre 101,102,...,201,202,... même si l'application ne les a pas envoyées dans cet ordre. Voir http://kerneltrap.org, mon lien précédent, ou Linux Journal (chercher elevator) pour les détails.
A tester en tout cas c'est facile.
 
La conclusion c'est que le réordonnancement des requêtes, tout autant que le cache disque, c'est indispensable, mais tout autant que le cache disque, ça n'a rien à faire dans le silicium du contrôleur du disque. C'est tout ce que je dis.
EDIT: orthographe.

OK c'est juste que dedans il est dit explicitement que les bio sont triées. C'est la seule chose dont j'ai besoin pour mon argument.

cf ce (vieux) topic très légèrement polémique ...

Au passage ces
notes sur l'ordonnanceur du 2.6.5 présentent très brièvement les différents ordonnanceurs implémentés.
En particulier ils sont bien plus sophistiqués que tout ce que peut implémenter une puce intégrée limitée à 256 requêtes ...

Ce topic est quand meme
 
Le cache disque n'a pas pour fonction que celle de cache toute bette, il ne contient pas les 8 dernier Mo transferer par l'HDD et basta... Je crois meme que c'est pas du tout ca et beaucoup plus complexe... Il n'a donc pas du tout le meme fonction, ni le meme fonctionnement que le cache disque de l'os...

Le truc que tu comprend pas, c'est que si l'HDD ou le controleur SATA font ca tout seul, on y gagnera forcement en perf... Moins de charge CPU, moins de RAM utilisé... Bref que du bon...
 
Car perso j'ai pas 256Mo a alloué a un cache disque enorme Surtout qu'une fois que tu lance un jeux ou une grosse appli, paf, il est vidé en partie par l'OS car il peut plus se permettre d'avoir autant de memoire utilisé "inutilement"... Du coup l'efficacité de systeme dimimue grandement...
 
Apres la gestion "native" par l'OS de la reorganisation des commandes HDD c'est pas bete c'est sur... mais vu que le controleur SATA le ferai apres, c'est sans doute utile surtout pour l'ATA et les SATA sans NCQ...

 
Je pense que je l'ai très bien compris au contraire. A partir du moment où te es d'accord que l'OS pourrait très bien faire ça tout seul on en revient à comparer:
1) NTQ intégré au contrôleur:
 - algo simple, intégré au disque, non-modifiable
 - exécuté par un petit processeur RISC
 - ayant une vision réduite (256 requêtes)
2) OS:
 - algo aussi complexe que tu le veux (cf ce lien), modifiable à la volée (/proc/sys/sched/*)
 - exécuté par un CPU à 2GHz
 - ayant une vision globale du problème (ie liste complète de toutes les requêtes à venir).
En particulier au niveau de l'OS tu fais au moins aussi bien qu'avec une puce dédiée.
Exemple extrême: active le mode laptop de ton noyau et met le délai d'expiration du cache à 1 minute. Lance une grosse appli à accès en écriture bien aléatoires. Le contrôleur intégré n'optimise que sur 256 requêtes. L'ordonnanceur de l'OS optimise l'ensemble de toutes les requêtes émises depuis 1 minute. Je pense que tu comprends pourquoi c'est forcément mieux.
 

Sur mon PC (qui boote sur le réseau) j'ai 1Go de RAM dont 800Mo de cache "disque" environ ...
 

Le coût CPU est complètement marginal.
 

Il ne t'a sans doute pas échappé que c'est le même "glacote" qui l'avait lancé ...
 

Je crois que tu ferais bien de lire ce topic avant de tirer des conclusions hâtives. En bref: quel que soit l'algo (aussi complexe et savant soit-il) qui est employé par le gestionnaire de cache intégré au contrôleur, tu peux le réimplémenter directement au niveau du cache de l'OS. Tu y gagnes la souplesse (modifiable), un CPU à 3GHz, de la RAM à  4Go/s (contre au mieux 150Mo/s sans parler de la latence), [EDIT] et évidemment la capacité (par exemple 200Mo contre 8Mo).
 
Je me contente juste ici de reprendre exactement le même argument à l'encontre du Native Command Queueing. Réordonner les requêtes, c'est évidemment très bien, mais ça n'a rien à faire dans le silicium du disque. Au pire du pire ils n'ont qu'à sortir un pilote spécifique à leur disque (cf MaxBlast ...).

Si t'as un PC avec 1Go de RAM juste pour faire un gros cache disque, libre a toi, mais personnellement, je prefere ajusté la taille mémoire a l'utilisation du PC... Et hormis pour un PC avec des gros jeux, j'ai pas besoin de plus de 512Mo sur les 3 autres PC qu'ils y a chez moi. Du coup j'ai vraiment de moins en moins de mémoire pour un cache disque...
 
Pour moi le problème ici c'est que tu ne vois que la vision globalle de la situation... L'OS pourrai effectivement comme tu dit reorganisé tout ca, mais c'est pas son role je crois. L'ideal je crois aurait été que les controleur SATA soit epaulé d'un DSP et de cache... Car combien ca couterai 64Mo ou 128Mo de cache DDR266 ECC ? Pas grand chose... Mais le SCSI le fait deja finallement
 
Je crois plustot, personellement, que le NCQ est vraiment un plus... Ca permet de mieux equilibré la charge globalle de travail... Et c'est ca le plus important... Pendant que le controleur SATA reordonne gentillement les requetes, l'OS peut utilisé le CPU qu'il aurai perdu a autre chose...
 
Du reste ton approche n'est pas mauvaise, mais n'est viable que dans une approche serveur/workstation avec un gros espace de RAM et voir meme du Bi-CPU... Mais pour moi ca ne serai qu'un plus et pas un remplacement aux NCQ...
 
Car il ne faut tout de meme pas oublié que les NCQ c'est un reordonnement dynamique...

Je ne lui ai pas spécifiquement dit d'utiliser 800Mo de cache; lorsque je retouche une image scannée évidemment le cache s'efface pour faire de la place à l'appli ... C'est l'OS qui décide ce qui lui semble le mieux.  
 

Je prétends précisément que c'est son rôle, parce que justement il peut faire ça mieux que n'importe quel contrôleur intégré.
 

Sauf que l'utilisation du CPU dédiée au réordonnancement est complètement marginale: il s'agit en gros d'insérer la description d'une nouvelle requête dans une liste triée (en O(log(n) donc); combien de cycles, même avec une énorme liste de requêtes à accomplir de 100 accès différents ? 300 cycles, soit 0.1 micro-seconde ?
 

La question de la quantité de RAM n'a rien à voir avec le réordonnancement (même si elle a tout à voir avec le cache disque).
 

L'OS aussi, bien entendu: la liste des requêtes en attente est toujours triée, quel que soit l'ordre dans lequel elles ont été soumises par les applications.
 
Je dis juste que vu que ça ne coûte presque rien en CPU, et que l'OS a bien plus d'infos pour le faire, pourqoi s'embêter à câbler ça en dur dans une puce ?
Ca ne sert à rien (le S-ATA non plus, mais bon comme on dit un troll à la fois).
 
Ce qui fait la qualité d'une interface, c'est son débit, la facilité à la brancher (vive la fragilité du SATA), l'ubiquité (le SATA-II inclura la connectique externe), l'évolutivité, etc. Mais rajouter un protocole pour faire faire à un disque dur ce qu'un OS fait bien mieux ...

Pour le coup du cache, si c'était si efficace pour le prix que ça coute il spourraient carrement y aller a coup de 128 mo intégrés sur le disque..

* Les caches disques utilise de la SRAM... C'est cher... Et deja Seagate emboite le pas avec 16Mo de cache sur les 7200.8 SATA (y'aura aussi des modeles 8Mo bien sur)...
 
* De plus pour les NCQ faut voir que l'HDD reordonne dynamique les instructions en fct° de l'emplacement de la tete...

Ce serait toujours aussi idiot. Autant laisser l'utilisateur choisir combien il veut de cache, et laisser l'OS le gérer puisqu'il le fait bien mieux.
 
 

C'est peut-être vrai, mais je ne vois vraiment pas pourquoi, vu que tu es limité derrière par le débit (150Mo/s) et la latence de l'IDE. Je ne vois pas comment le disque pourrait aller plus vite à écrire des données en RAM, même avec de la SRAM qui tue, que si l'OS les y avait déjà mises lui-même ... A mon avis c'est de la bête RAM bien de base.
 

Réveil ! Le disque dur ne va rien réordonner du tout, dynamiquement ou pas, puisque les requêtes qui lui parviennent seront déjà ordonnées  ...

bon faut arrêter là
 
Le cache disque sert essenciellement de tampon
c'est un cache qui est régler en rapport aux perfs physique du disque et à leur capacité
Le cache ne doit pas êtres trop grand au risque d'"étouffé" le disque de données à inscrire physiquement
Mais il doit avoir une certaine taille pour qu'il soit efficace
 
Le transfert série nécessite un cache plus important pour stocké le flot des données codé en 32bits ou 8bits (à vérifier vis à vis des spé de la couche hardware sata)  
 
remontons à 7,8 ans, les disques de l'époque avait 512k à 1mo de cache en EIDE, en SCSI 2 à 4 mo de cache parfois extensible à 8 pour certaine utilisation serveur
 
il y a 7, 8 ans les disques IDE n'était pas équipé de cache en écriture
 
Pourquoi les fabricants augmente-t-ils le cache disque proportionnellement au perfs DD alors qu'effectivement ce type de mémoire ségmenté et trés cher ? vraiment son con ça fait des années ah oui c'est vrai, quand on est con c'est pour la vie
 
Pourquoi avoir implanté le cache en écriture sur l'IDE si c'est inutile ?
 
Pour le TCQ pourquoi l'avoir implanté depuis les normes SCSI2 et conservé alors qu'en logiciels ce serait plus performant ?
 
"tiens merde j'ai dépasser le secteur sur lequel je devais lire, pourtant c'était bien dans l'ordre ! bah ouai mais bon c'était un peu trop prêt du seteur que j'ai lu précédament
merde je doit faire demi tour, OS vite viens à ma rescousse"  
 
de toutes façon sur ce dernier point, le seul conseil que je peu vous donner c'est de remettre votre raisonnement en question et de vous informer plus sur le fonctionnement d'un PC vous finirez par comprendre que c'est inutile de contester.
aprés vous croyez ce que vous voudrez et si vous changer pas d'avis, vous pesterez contre les fabricant qui implante des truc cher pour rien..
 
Au fait, vis à vis des serveurs de base de données, vachement utile d'utiliser du cache RAM pour réorganisé les requête lorsqu'une opérations s'éxécute sur une table de 2Go et que le serveur n'à que 1024mo. chouette du swap...

mdr

ouf j'suis pas le seul a pense qu'il est un peu a coté de la plaque par moment glacote

Bon j'arrête alors.
 

Je prétends qu'au-delà de 2Mo c'est strictement pour des questions de marketing.
 

Parce que le principe du SCSI était "tout faire faire par le contrôleur et le moins possible par le CPU". Aujourd'hui les CPU sont bien plus performants et peuvent largement traiter ce genre de choses pour un coût marginal.
 

Je n'ai pas compris. Le secteurs de numéros consécutifs ne sont pas contigüs sur le plateau, mais sont espacés de façon à ce que quand le traitement du secteur de numéro n est fini, la tête est au-dessus du secteur n+1 (entre temps le disque a pu faire 1/4 de tour).
 
Si tel n'était pas le cas, comment les transferts DMA pourraient-ils fonctionner avec de bonnes performances ?
 
Pour lire les secteurs 100,101,102,...,150 il n'y a pas de meilleur agencement possible que de les demander dans cet ordre. C'est tout.
 
NB: ça marche même quand on arrive en bout de plateau; dans ce cas on numérote en partant du bord du disque puis vers le centre puis vers le bord etc. Bref si vous n'êtes pas d'accord, demandez-vous comment marche un accès DMA.
 

Je suis tout-à-fait ouvert à la critique, à condition qu'il s'agisse d'un argument nouveau. Je pense avoir donné des arguments précis.
 

Parce qu'il y a des clients pour l'acheter. De même qu'il y en a qui préfèrent l'ATA-133 à l'ATA-100 parce que "ça va plus vite" ...
 

L'OS se débrouille précisément pour arbitrer entre le cache et le swap. Il peut très bien avoir 500Mo de cache disque mais mettre des pages inutilisées en swap pendant ce temps. De toute façon, je n'ai pas dit que l'OS allait toujours parvenir à tout mettre en cache, je dis juste qu'il fera quoiqu'il arrive toujours mieux avec 300Mo de RAM à 4Go/s qu'un contrôleur intégré avec 8Mo à 150Mo/s ...
 
PS: désolé pour mon ton aggressif, c'est l'émotion de toujours répéter les mêmes choses ...

Tant mieux, j'aimerais être convaincu (comme 66% des lecteurs de ce forum) que j'ai tort sur ce point, parce que c'est frustrant de passer systématiquement pour un c...
 
Aurais-tu des arguments pour aller avec ?

Le disque reordonne dynamiquement en fonction de l'emplacement de la tete a l'instant t et des secteurs qu'il a a lire et a ecrire...
 
L'OS ne peut pas savoir où est la tete, et peut ordonné les secteur en fonction de leur ordres sur le disque, mais si la tete est au milieu de cet amas de secteur, elle va d'abord lire les premier qu'elle peut lire et apres traiter les autres, au lieu de se deplacer pour lire du premier au dernier, dans l'ordre...

Disons que a l'echelle de l'OS tout a tout a fait raison, mais que a l'echelle du controleur disque et du disque, tu reste trop sur tes positions qui sont que si l'OS fait bien son boulot, pas besoin de gros caches et de NCQ...
 
Alors que finallement ce sont des optimisations toutes deux utilent et meme complementaire....
 
Par moment je me dit que finallement un site specialisé dans le stockage et le RAID aurai pas été mal C'etait melba qui avait euh cette idée...
Ca aurai été pas mal je crois, car franchement, je crois que ca serai bien de tout regroupé nos infos et de completer nos raisonnements...

Merci pour ton point de vue (et merci d'avoir gardé ton calme ).
J'arrête ma "pollution" ici (je ferai un topic dédié si besoin).

 
Non, oui mitigé sur les premier disque IDE
 

 
As-tu du SCSI actuelle, utilise tu des application qui demande beaucoup d'accés I/O ?
Au vu de cette réponse non
 
je le voit pratiquement tous les jour de part mon boulot
entre passer 1heures à regarder sont P4 3Ghz ou son XP3200+ calculer 5 secondes, puis swapé 512mo pendant 2 minutes sur le disque IDE 7,2k tout récent de l'OS, pendant que le DD IDE 7,2k aussi récent écrit une broutille toutes les 3minutes
 
et faire la même opération en 15minutes total (ç'ta dire bien moins qu'une minute en swap) avec juste 2 DD SCSI 10K sans raid pas au top en plus, y'a pas photo les gain du SCSI sont toujours d'actu et pas seulement à cause des 10K. si non cette interface aurait était abandonnée depuis longtemps, et on utiliserait pas des carte RAID SCSI pour gérer des baies de disques dur IDE avec un adaptateur IDE>SCSI par souci d'économie
 

 
Dans la théorie oui, dans la pratique non. Le temps d'avoir la commande suivante en file d'attente, la têtes peu se retrouver à n+2 voir n+4 avec de trés petit fichiers ou les perfs disques chute rapidement à 3/5mo/s sur les débits constants
 

 
vois pas le rapports, quand le têtes loupe un secteur , les têtes reviennent légérement en arriere et les disques font quelques tours de plus (réduit généralement à un tour car performance de latence oblige)
Donc le transfert DMA, benh quoi ?  
l'ordre de lecture n'est pas changer. et si le transfert DMA n'avait aucune tolerance aux débits non constant, benh "marcherai pas trés bien le PC !"
 
Ensuite c'est bien 255 commandes en simultané en SCSI, IDE 8 (ça à peut êtres évoluer depuis à vérifier)
benh entre la 8éme (150) et la 9éme (151), paf la tête est à (152)
hop rebelotte, retour en arrière. avec le TCQ le 151 est laissé de coté puis relus lorsque la têtes repasse dans le coin
 

 
bah oui j'ai répondu à t'es arguments "précis",  
L'optimisation logiciel comme le dit Mei est interressante, mais n'à rien à voir avec celle du TCQ même si y'a des similitude  
Le TCQ ne peut absolument pas êtres réalisable coté logiciels sans de trés gros ralentissement et utilisations de bande passante pou rien.
 
tu perciste à contredire des arguments qui effectivement ne sont pas nouveau car la technologie est approuvé depuis le SCSI2 et finalisé, normé et n'a pas à changer puisqu'elle fonctionne impect !
 

 
oui, c'est assez commerciale
enfin le PCI est à 133Mo/s, c'est plus valable maintenant mais à une époque ça permettait d'avoir moins de latence sur les echange PCI/IDE.  
mais pour ce que ça changer en pratique.
 
IBM voulait appellé l'UDMA100, l'UDMA 66+ et il avait pas tout à fait tord non plus à cause des timming et cycle des différents bus...
 

 
pffff un cache mémoire et un tampon bien que basé sur le même principe ne fait pas appelle à la même optimisation.
 
Pour ce qui est de la méthode de réorganisation, voir les multiples réponses répéter au dessus !
les deux permettent plus de perfs, moins de latence et d'autant plus si il sont combinées
 

 
non sans blague et nous non peut être ?
Enfin je m'excuse aussi pour le ton agressif de mes réponses.

bien les notes sur l'ordonnanceur du 2.6.5    
t'es sûr de bien comprendre ce qu'il explique ?

 
Salut tout le monde, j'aurais besoin de renseignement sur le Raid, à savoir, j'ai actuellement un seagate 120 sata 8mo cache en fat32 et je vais acheter un autre dd identique pour faire du raid0, alors ce que je voulais savoir c'est, est-ce que le fait de passer en raid0 me permet de tourner en ntfs et d'avoir des performances en lecture et écriture au moins équivalentes à du fat 32 sans raid en clair
est-ce que, pas de raid+fat32 = raid0+ntfs ??????
Merci à vous    

Les perfs du NTFS sont en réalité tout aussi bonne, c'est une question de fonction (sécurité etc...) lors de la copie de DD à DD
mais en lecture sous les logiciels c'est tout aussi speed, voir plus dans le cas de grosse partition et si le disque est rempli.
En réalité la FAT32 donne une impression de rapidité, en utilisation logiciel, swap de l'os etc... il n'en ai rien la Fat32 est généralement légérement moins rapide
tu peu aussi optimiser le NTFS en désactivant certaine fonctions du registre ici:
 
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem]
"NtfsDisable8dot3NameCreation"=dword:00000001
"Win31FileSystem"=dword:00000000
"Win95TruncatedExtensions"=dword:00000001
"ContigFileAllocSize"=dword:00002000
"NtfsEncryptionService"="Efs"
"NtfsDisableLastAccessUpdate"=dword:00000001
"NtfsMftZoneReservation"=dword:00000002
"AsyncFileCommit"=dword:00000001
"ForceRMIO"=dword:00000000
"DriveWriteBehind"=hex:01,00,00,00
 
Mais bon tout dépend de l'utilisation réel, la Fat32 peut paraître plus rapide sur certaine éxécution qui demande peut d'accés et des disques de petites quantité (partionnement d'un DD possible)
 
Pour les perfs d'un raid0 deux disques, benh c'est un peu prêt le double en débit comparrer à un seul DD
en temps d'accés et dans la pratique, trés peu de gain en raid ATA (on va dire 4/6éme), pratiquement 2/5 du temps d'accés d'un seul disque en SCSI
mais c'est aussi sujet au contrôlleur Raid et la taille du strip et des fichiers à inscrire
 
Ce seras forcément plus rapide en NTFS raid0, surtout 240go qu'avec un disque en FAT32