Reprise du message précédent :

si en hardware l'OS voit un DD
en soft c'est une partition en agrégats par bande, donc tu peu en créer deux avec chaque moiter des deux disque par exemple

Oui si tu lit un fichier pas fragmenté
 
Mais dans en pratique sur certaine opération ça ralenti fortement
 
les frabricant ne parlerai jamais de temps de latence maximal, il évite juste de l'évoquer pour des souci commerciaux, mais sur des disques pro généralement ils sont donnés, même si on peu les doubler dans la réalité !
 
Et puis si la solution logiciels valait réellement plus la peine que le TCQ, les fabricant se ferait pas chier à implanter ça sur le SATA
Le TCQ demande des transfert interne au DD extrêmement rapide et de technologie coûteuse. bien plus rapide que la RAM de l'OS et son proco
c'est pas viable d'implanter une tel technologie juste pour avoir un argument commerciale sur des disques à vocation économique.
 
si non un autres extrait des propos de Jc Bellamy :

avec l'augmentation de la densité et perfs, 512ko pour un secteur commence à devenir hard pour les têtes !

bon de la doc sur le TCQ :
http://www.pcguide.com/ref/hdd/if/scsi/protCQR-c.html
 
sur le raptor avec un p'tit schéma explicatif en prime :
http://www.wdc.com/en/library/sata/2579-001076.pdf
 
et ce p'tit schéma va remuer les méninges !
 
un indice supplémentaire: on peu faire plus fort en lisant dans cette ordre c, b, a si la têtes est au cylindre de C
 
en tout cas c'est sûr, c'est impossible pour l'OS de prévoir ça aussi bien que le DD !

Merci.
OK je suis d'accord, l'hypothèse "la meilleure façon de lire les secteurs [100,101] est de les demander dans l'ordre croissant" est donc fausse. L'exemple de Western Digital est bien; cela dit (comme je déteste avoir tort) je remarque que ça ne marche que pour des accès à des secteurs isolés (ie ça peut aller plus vite de demander 300,500,400 que 300,400,500). En revanche pour l'accès à des secteurs consécutifs ([100,200])je pense encore qu'il n'y a rien de mieux que l'ordre croissant.
 
On en revient toujours à la même question: est-ce que l'OS fait plein de petits accès isolés ou quelques gros accès contigus ? OK si le fs est fragementé les accès seront effectivement isolés.
 
Donc je suis d'accord que si tu as un fs fragmenté, le TCQ est très certainement utile.

L'OS ne fait que rarement que gros access... Enfin dans une utilisation courante... On lit jamais toute une DLL d'un coup par exemple...

1) En lecture: l'application ne va peut-être pas demander toute la bibliothèque, mais l'OS lui va la charger intégralement en mémoire (read-ahead).
2) En écriture: les différentes applications vont peut-être faire des écritures ponctuelles successives et désordonnées (ex:BDD) mais l'OS lui va attendre un peu (de 5s à 1min) avant de tout écrire d'un coup d, de  façon contiguë et ordonnée.

Sur le disque PHYSIQUE (pas seulement la partition donc), sous windows, où y'a l'OS, le cache en ecriture est desactivé par defaut... Apres je sais pas ce que ca change... mais ca doit permettre de ne pas perdre de donnée en cas de coupure de courant...

bon en fait ça dépends surtout de l'application
 
Cas de photoshop :
Photoshop à sont propre cache, le fichiers de travail et des fichiers temporaire qui augmente au fure et à mesure que l'on bosse sur un fichier (bout de fichier laisser de coté historique, retour en arrierre etc...) il prends en autre une place en mémoire pour les fichiers du programme principale, et charge quand besoin les fichiers supp.
Il réserve aussi une place pour un cache mémoire pour le fichier de travail.  
Lorsque photoshop éxécute des commandes, il éxécute aussi des commande propre à l'interface de l'OS et il a besoin de faire des demande à l'OS (drivers etc...),L'Os à besoin de mémoire c'est clair et dans le cas ou il en manquerai, il swap.
 
donc en gros avec un fichiers de travail de 1Go, un document de 125mo en format PSD et 512mo de ram
une commande de redimmensionnement au double des dimension  
H, L d'impression à la même définition (300dpi, format A2 à A1 par exemple)
Le document à contenir en mémoire passera de 512mo à pratiquement 2go facile (4x le nombres de pixel)
tout va être solicité en même temps, le proco + le disque pour écrire l'historique/fichiers temporaire ou lire le fichier de travail, la mémoire va se rempli jusqu'à un certain pourcentage, L'OS va swapper, le logiciel aussi videra sont cache pour libérer de la place en même temps les opérations sur le fichiers continu
Le disque va éxécuter énormément de requêtes sur des secteurs totalement disparate en même temps et totalement mélangées, un bout du swap par ci et là, un bout des fichiers temporaire, un bout du fichier de travail  
 
si le disque est pas assez rapide et reçoit des bride de requête pour qu'elle soit organisé (Histoire des temps d'attente pour voir quel requête sont les suivante), le CPU ne seras pas du tout alimenté pendant les opérations de SWAP et sera en stand by pendant un bon moment
L'opération de dimensionnement triplera voir quadruplera en temps comparrer au temps de calcul du CPU
 
Par contre si les paquet de commandes sont envoyer d'un coup au DD
Le TCQ du SCSI permetra entre autre d'en recevoir jusqu'à 255 commandes simultanément et de déconnecter le disque des timming du PC(disconnection:fonction particulier du SCSI associer au TCQ) , pour permettre de gérer les opérations plus rapidement d'écriture/lecture gràce à une totale indépendace vis à vis des temps d'attente que les demandes timmées de la RAM, CPU provoque.
 
enfin pas trés bien expliquer, mais je pense qu'on en comprendra le principe, surtout lorsqu'il y a plusieurs DD SCSI par exemple l'un comporterai OS+swap, l'autre logiciel+fichier de travail et temporaire
 
un peu comme une course de relai, si un courreur est lent (disque dur), le courreur suivant doit attendre le baton
Le tcq+déco permet au reste du PC qui représenterai le courreur suivant de courrir avant que le baton arrive.
(pas terrible non plus comme explication, je l'avoue )
 
Le NCQ semble avoir associer la disconnection au TCQ ata
 
Pour les base de données, voir cette article qui l'explique trés bien :
http://cerig.efpg.inpg.fr/Note/200 [...] sation.htm

Edit : Sous Win2K3 c'est différent Y'a la cache en ecriture, mais on peut activé performance avancé (si l'HDD est sur alim de secour...)
 
Du coup y doit parlé du cache du disque en lui meme...

Je ne comprends pas du tout pourquoi. L'application graphique et le gestionnaire de swap vont transmettre des requêtes de façon totalement disparates, ça c'est sûr. En revanche, l'ordonnanceur (au niveau du pilote de disque dur) va, lui les transmettre de façon ordonnée au disque dur. En outre ces requêtes seront certainement contiguës (toute l'image finit par être traitée, soit un gros bloc contiguë de l'espace d'échange).
 

Oui mais l'OS n'envoit justement pas ses requêtes aussitôt qu'il les reçoit ! Il les groupe et les envoit par salves.
 

 
Merci pour ces précisions. Je suis totalement d'accord sur le principe selon lequel trier et regrouper les requêtes permet d'accroître énormément les performances.
 
Je persiste néanmoins à dire que l'ordonnanceur (au niveau du pilote de disque) le fait déjà, depuis Unix et même SmartDrv.exe sous DOS 5.0 (1993): la meilleure preuve en est qu'il interceptait CTRL+ALT+DEL pour vider le cache en écriture avant de rebooter. Quoi que l'application ait voulu faire, de toute façon ses requêtes désordonnées étaient déjà interceptées par SmartDrive pour y être regroupées.
 
EDIT: exemple typique, ton application/le swap modifie dix fois successivement un morceau du même secteur sur disque; il ne sera bien-sûr écrit qu'une seule fois, à la fin, et non pas dix fois.
 
Je fais en plus l'hypothèse (rectifiée suite à l'exemple de Westren Digital, merci) que la majorité des requêtes sont contiguës (ie > 10 secteurs consécutifs, soit 40ko) et donc qu'il n'y a pas d'odre plus efficace que l'ordre croissant.
 
J'en déduis que l'ordonnanceur (du pilote de disque dur de l'OS) fait déjà dans la majorité des cas (contre-exmple: Western Digital ...) le travail censément accompli par le Taggeed/Native Command Queueing.
 
Si tu n'es pas d'accord avec ma conclusion, peux-tu me dire précisément où dans ce raisonnement (que j'espère simple) ?

 
Lors d'un vidage de la mémoire, le noyau (gestionnaire mémoire) d'NT n'opère pas du tout de la même manière, il fait appelle à une autre INT que l'INT13 du bios CM ou SCSI/Carte additionnel
cette INT permet seulement de connaître le début de l'emplacement du fichier de swap
cette fonction est interne aux noyau et indépendante du reste du système pour pouvoir fonctionner en cas de crashe (fameux vidage de mémoire lors d'une page bleu)
d'ailleurs en cas de crashe et avec un swap inférieur à la taille de la mémoire (et certain réglage de la copie d'image complète de la ram) le disque continu d'écrire à la suite du fichier swap en écrasant les éventuelle données contenu
cet accès est directe et prioritaire, il ne passe pas par le cache mémoire (qui est contenu dans la ram ! donc peu lui même êtres vider).
 
le gestionnaire de mémoire ne videra pas toutes la mémoire, mais les partie les plus ancienne.
le disque devra donc inscrire un bloc mémoire ordonné en fonction des emplacement mémoire à vider et reprendre au dernier emplacement le prochain bloc mémoire swapé.
les requête prioritaire du swap peuvent se retrouver en liste de queue du disque, mais prioritaire. elle s'intercale passant outre l’ordonnance de la liste.
 
Tans que le fichier n’est pas calculer en entier, le gestionnaire devras vider les parties du swap, voir en recharger en mémoire vive pour continuer le calcul
 
Le fonctionnement du gestionnaire de mémoire est décrit sur le site www.bellamyjc.net
Mais je sait pas ou il a placer cet article, je l’avais lu y’a déjà quelques années.
cela expliqué les probléme d'installation d'NT4 avec certain disque IDE pas compatible avec l'INT utilisé. (révolu depuis les années 1996/97)
 

 
sans commentaire
 

 
certes le disque dur est le maillon le plus lent, toutes optimisation est bienvenue
 

 
Non CTRL+ALT+DEL fait appel au gestionnaire de mémoire sous NT ===> le noyau système. l'accès de vidage de mémoire ne se fait pas par l'INT13 et ne passe pas par le cache disque de l'OS ou par SmartDrive (qui est en autre un cache tampon, comme les cache mémoire du disque en lecture et écriture)
 

 
Non l'image du fichiers temporaire est constituer petit à petit au fur est à mesure des calculs opérés par le CPU
il seras écrit au coup par coup
entre deux le gestionnaire de mémoire devra libérer de la mémoire pour continue à exécuter les modifications de chaque pixel/ligne du fichier.
 

 
Oui si c’est contigu,  
 
le paramètre « ContigFileAllocationSize «  de la base de registre Windows oblige le disque d’écrire sur un secteur contigu libre d’une certaine taille (512Ko par défaut). A 512 Ça limite la fragmentation et permet d’inscrire un fichier de 512ko sur 1024 secteurs contigus
 
Cette optimisation est très intéressante pour la vidéo et le direct to disque. Bref  les gros fichiers
 

 
Pourquoi ? c’est loin d’être la majorité des cas ! la fragmentation des fichier d’un disque dur le prouve bien !

Très bien. Je suis complètement d'accord qu'un test à la hdtach / hdparm -T va te dire que le TCQ/cache intégré 16Mo sont utiles. Maintenant regardons ce qui se passe dans la vraie vie
StorageReview ne fait pas un simple hdtach ou atto. Ils passent leur disques dans une batterie de tests applicatifs, serveur ... la vrai vie  

OK, tu as raison. Simplement Win32 je ne connais pas trop (personne ne connaît d'ailleurs hors 1 Microsoft way); en particulier il me semble que le cache n'est qu'au niveau du système de fichier, pas au niveau du mapping périphérique->pages mémoire comme sous Linux2.6. Les bio, drivers/block/ide-tcq.c, c'est public, documenté, discuté (LKML). Donc il me paraît possible (sinon probable) que le noyau 2.6 soit plus à jour à ce niveau-là que Win32.
 
Je vais chercher un benchmark sous Linux genre bases de données, ou alors les prochains benchmarks de Reiser4 ...

glacote --> Perso quand je vois comment reagit mon HDD sous Win2K3
 
Genre copie disk-to-disk d'un ISO de WinXP... Les fichiers defile trop vite... mais au final ca gratte tres peu souvent, ca doit gratté 1s toutes les 5s...
 
Sous WinXP il me semble que ca grattait plus... Meme si d'accord c'est pas les memes disques non plus...

Merci pour l'info, mais alors comment je dois créer mes partitions quand mes 2 disques sont en raid0 ?? A part partition magic bien sûr.

en fait en Raid soft c'est la partition qui doit être en agrégats par bande
pour ça :
clic droit sur poste de travail W2K/XP, passer les deux disque en mode Dynamique en cliquant du droit sur l'onglet des disques
 
puis sélectionne la partie non alloué d'un des deux DD, clic droit créer une nouvelle partition
choisir le type de partition "volume agrégat par bande" (ou Raid0 stripping) et sélectionné le second disque dans la liste ensuite, fixer la taille etc..., refaire l'opération de création de partition si plusieur partition
 
pas sûr que partition magic sache créer ce type de partition, y'a déjà du mal à gérer les disque dynamique avec des volume simple

bah sous W2K ou XP ma led du boitier branché sur les carte SCSI se voit à peine tellement le temps de copie est rapide des donnés, c'est rare de la voir allumé à font, du coup ça prouve bien que win est vraiment pas optimiser pour les disques rapide en U160/U320! Sous Linux ou avec une carte U2W c'est autre chose !
d'ailleurs je vais p'tet ressortir ma vielle U2W

Win2K pas optimisé pour les disque rapide
Utilise l'advanced server

 
Heu merci encore (j'arrête pas de me coucher moins c.n les soirs en ce moment ) mais ce que je comprends pas c'est pourquoi tu me parles de Raid0 software, moi ce que je veux c'est monter de DD SATA en Raid0 sur ICH5R, donc Hardware ????? Je sais pas si c'est que j'ai pas tout compris ou que je me suis mal expliqué.....  

si raid0 hard Ok, tu peu utilisé Partition Magic aprés
L'OS ne verra qu'un DD, l'Array raid0 hardware

bonjour tout le monde,
 
drapal

Ha Ok, merci, j'avais bien compris alors  
Drapal alors.  

tout ce que je peu préciser cest que la gestion de la mémoire de winnt est calquer sur celle d'Unix
aprés que NTFS est le premier systéme avec une MFT, fichier journeaux et que ceux de Linux sont semblable.
 
La partition spécial pour le swap sous Linux est une trés bonne solution aussi
Le formatage des disques sous les sytèmes linux est plus rapide aussi
 
encore que toutefois y'a des exception trés étrange parfois sous windows comme avec ma carte raid je formate en NTFS une array de 36go en moins de 5secondes avec un disque de base ??
En dynamique ça formate avec un temps classique
 
Mais certe au niveau drivers ça fonctionne pas du tout pareil.
 
Ensuite Linux semble trés friant des temps d'accés du disque dur
et fonctionne vraiment trés trés bien en SCSI
 
J'ai été étonner d'avoir pu constater des perfs supérieur avec un vieux dd de 7200tr/min U2W de 4,3Go et d'un débit max de 11mo/s à un segeate IDE U6 de 5400tr/min, 20Go et d'un débit maxi proche des 30mo/s !
 

Le temps de formatage est directement influé par la vitesse de disque dur, vu que la premiere etape c'est la creation du systeme de fichier (~30s) et le reste c'est un test physique en lecture sur tout l'HDD... Donc si Linux va plus vite, c'est qu'il verifie moins en profondeur.
 
Sinon sur les Array RAID avec cache, si c'est instantanné, c'est que le controleur fait "croire" a l'OS que la verification est effectué alors qu'il ne la fait pas en direct... Vu que logiquement cette verification est faite periodiquement lorsque les HDDs n'on rien a faire et de plus les HDDs sont monitoré via le SMART...

Puré ça prends un temps fou de vérifié la partition !
y'a juste un truc que je pige pas tout à fait dans ce cas
c'est pourquoi une fois mon array raid0 passé en disque dynamique le formatage NTFS met 10/20 minutes (temps normal) alors qu'en disque de base 5 secondes ?
 
faudrait que je repasse en disque de base en fait, avec un ghost ça peu marché ?

Avec un ghost ????  Arghhh  ! je pense que ghost memorise le type de partition afin de pouvoir redescendre correctement une image sur un dsk vierge. C'est pourquoi je serais tenté de dire que cela risque de ne pas marcher.

Ghost utilisera la taille maxi de la partition, et il faut juste que la partition soit assez grande pour contenir les données sauvé...

oui certes  
 
En fait ma question est :
la sauvegarde d'une partition en volume simple sur un disque dynamique peut elle être recopier sur le même disque remît en disque de base sur une partition principale ?
 
En gros juste sauvegarder les données du disque systéme pour les replacer dessus aprés avoir refait mon array et viré la gestion dynamique du disque (qui semble ralentir plus qu'autre chose les perfs sur mon systéme).
avec une simple image systéme sous néro ?

bah le pb reste celui de windows... a mon avi au boot ca risque grandement d'etre un beau bluescreen

+1

Non, en principe ça fonctionnera
 
en fait le disque dynamique est juste une inscription de signature et un 1 au lieu d'un 0 dans une entrée du MBR pour indiqué que c'est l'OS (enfin le noyau au boot selon l'info du MBR) qui gére l'adressage du disque au lieu de contacter l'INT13 du bios (CM ou SCSI)
en réalité y'a juste une partie du dd qui contient l'adressage plutôt que le bios et elle sera effacer par le reformatage, la partition étant refaite normalement sur le disque de base, les fichiers seront correctement inscrit dans la MFT.
Le noyau au boot réagira de suite avec l'option de gérance "normale" par le matériel (bios SCSI entre autre)
 
Le probléme résidra essenciellement sur le boot.ini qui sera pas correct, mais ça je peu le corriger avec la console ou mieux prévoir un menu supplémentaire pour booter dessus avant la sauvegarde des fichiers.
 
aprés au boot le bios de la carte SCSI s'occupera de l'adressage normalement et les fichiers systémes (ntdlr, rep Windows) seront retrouver et windows bootera normalement car il refait à chaque démarrage les branches hardware du registre, la config coté disque sera corrigé de suite et avec le même drivers ou au pire avec un reboot pour corriger les données "corrompu".
 
Au pire sous winnt j'aurai peu êtres un blem qui met déjà arriver en changeant le disque de base en dynamique ==> "échec de l'écriture différé" arriver sous windows. mais ça c'est un probléme propre à mon matériel qui n'aime pas le mode de gestion dynamique de WinXP (sous 2K ça passe).  
je ne pense pas que ça posera probléme avec un retour en disque de base et une partition/table d'allocation refaite d'une manière classic, là le matériel est parfaitement compatible et winXP n'activera pas ses option de module de gestion dynamique, puisque pas de DD dynamique déclaré.

si tu le dis Melba. Mais je suis pas trop convaincu.  Tiens nous au courant.  
 
Merci.

faut que je trouve un truc pour sauvegarder le disque systéme
 
Je vais déjà l'oppérer sur mon array logiciel, là no probléme j'ai juste à faire une copie dans un rep des fichier sur un autre DD puis virer la partition et remettre le dd en disque de base
 
Pour la copie de la partition systéme, arghh !
soit un logiciel qui recopie une image en fonction de la nouvelle partition (pas du bit à bit qui recopirai exactement le disque en l'état dynamique)  
ou copier le dd en installant la carte raid sur un autre PC et faire un fixboot. mais là c'est chaud pour le fichier de pagination !
Une solution le transférer avant sur l'Array logiciel.

bon j'ai remit l'array logiciel en disque de base
pour ça no probléme c'était sûr
 
bilan = perf en copie de DD à dd un peu moins rapide, mais pas une grosse perte, par contre coté logiciel gros gain en ouverture et encore j'ai pas défragmenté pour qu'il en optimise l'ouverture !
 
Edit : vraiment c'est le jour et la nuit en fait, la led de la carte scsi s'allume en continu au lieu de ponctuellement, le temps est presque divisé par deux avec l'ouveture de certain logiciel
 
les dd gratte bien et c'est carrémént plus rapide. Autocad LT 2004 s'ouvre à peine moins rapidement que lorsqu'il est chargé en mémoire !
Photoshop pareil et Webexpert 5 instantané, aucune diff chargé ou non en mémoire ! avant y'avait un p'tit temps de latence au premier chargement
 
fait chier faut vraiment que je repasse l'OS en disque de base !  
J'ai pas envie de tout réinstaller et reconfigurer !

Pour moi mode dynamique = RAID0/5 Logiciel par windows...
 
Je comprends pas ton trip d'avoir passé en dynamique tes HDD s'il t'a deja une carte RAID hardware

aprés avoir refait mon array et viré la gestion dynamique du disque (qui semble ralentir plus qu'autre chose les perfs sur mon systéme)
ouinnnn ... j'envisageai de passer en RAID dynamique car sous nunux, je n'arrive pas à faire de raid-0 avec array :-(

bah en fait c'estait pour tester la différence
vu que Microsoft parle de meilleurs perfs des disque dynamique, pas seulement des mode raid
Et au final, benh c'est sûr un volume simple est plus rapide en copie de DD à DD, mais pour les logiciels c'est l'inverse car moins directe
 
Bon si non j'ai réussi à repasser le disque systéme ! pas de page bleu
mais des couilles qui m'oblige à réinstaller ! (enfin du moins une réparation du windows et reinstalle des mise à jours + config)
 
Réseau local inaccéssible, même en réinstallant (pourtant le PC est accéssible et sont réseau fonctionne des autre postes du réseau et sous IE)
Sous IE plus moyen de contacter tout les site en favorie ! paf erreur ==W surrement un probléme de MFT car les raccourci sont résidant à la MFT
Outlook fonctionne et le reste des logiciels aussi
 
bref assez zarb, pas de page bleu mais des merde pour écrire la MFT sur certain point
 
En mode sans échec avec le réseau, aucun probléme, même IE fonctionne !

Non c'est juste en volume simple
Ma carte RAID est une trés grosse carte qui fait du RIAD 0,1,0+1,5,6,7,10,50 etc..., c'est pour ça qu'il y des merde avec les perfs des volumes simple en dynamique
 
Pour du Raid soft, non t'inquiéte les perfs seront là, mais compte pas dessus pour y mettre le systéme contrairement au raid soft nunux
 
bon benh la récup à échouer, réinstalle propre en cour !  
tout ça pour pas grand chose en fait, sur le coup j'avais garder mes disque en dynamique pendant 3/4 mois vu qu'XP fonctionner impect, sauf les perfs disque légérement en retrais par rapport.
 
mais au vu de la diff coté logiciel et swap, y'a pas photo fallait que je tante.
ça aurrait été winnt4 je l'aurait fais les doigts dans l'nez, 2K ça aurait pu marché (pas ce probléme de MFT) mais XP ARGHHH!
 
en fait appriori et sûr à 60% que le probléme vient du multi-utilisateur des fichiers (c'est à dire versions différentes selon l'utilisateur d'un même fichier ou selon un point données etc...)
c'était en cour d'implémentation sous 2K (certain logiciel fonctionné d'ailleur) et apparrement bien implanté sous XP (logique c'est utile pour une workstation)

A priori les 16Mo de cache servirons pour les disques SATA natif + NCQ, puisque le Maxtor MaxLine III devrais aussi posséder de 16Mo de cache...
 
Arf, mais j'vais quand meme prendre du Seagate je pense Silence avant tout now

 
dite moi, chui en RAID0 sur le Chip de ma mobo (par ICH5R)
 
voulais, savoir, si ya pas de risk, de "cassage d'array" ou plantage total du RAID, en flashant le BIOS de la mobo ?? (faut s'attendre a tous avec c Maj BIOS now )