Reprise du message précédent :
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

Je prétends qu'au-delà de 2Mo c'est strictement pour des questions de marketing.
faudrait peut-être que l'on m'explique pourquoi les versions 2Mb sont sans exceptions moins performantes que leur homologue 8Mb.
Au fait ... le prochain seagate ne sortira pas en version 2Mb de cache ... uniquement 4 ou 16.
 
NCQ c'est le TCQ?
Si oui, là encore, pas la peine de tergiverser. Faut voir dans les tests. Les disques intégrant la fonction TCQ sont un cran au dessus notamment pour les applis serveur. A ce sujet, Storagereview a en prépération un article sur l'intérêt (éventuel) du TCQ
 
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
es-tu bien sûr que la bande passante du cache disque est de 150Mb/s?
 

J'envoie ce message depuis une machine avec 2 Seagate 10,000 RPM sur lesquels je fais de temps en temps tourner des applis scientifiques ...
En revanche je ne suis pas administrateur système.
 

OK mais je pense que c'est davantage dû aux performances intrinsèques des disques (50Mo/s, 6ms) que dû au protocole SCSI. Il vaudrait mieux comparer des SCSI 7200 à des IDE 7200 ou des SCSI 10000 à des Raptor ...
 
 

Je suis d'accord avec toi dans le principe: le scenario serait
 - accès à n+1
 - sleep 1ms
 - accès à n+2
 - sleep 1ms
 - accès à n+3
 - etc.
auquel cas, à supposer que 1ms = temps pour passer de n+1 à n+2, il vaudrait mieux demander n+3 après n+1 car la tête est juste au-dessus.
Mais ça n'arrive jamais car l'OS envoie ses requêtes par salves, car il a un cache. Bien entendu, si l'OS fait des accès explicitement synchronisés (sans cache), alors oui forcément le cache intégré tout autant que le NTQ sont utiles.
 

Dans ce cas les performances chutent dramatiquement. L'agencement des secteurs logiques sur les plateaux est prévu pour que l'accès aux secteurs n,n+1,n+2,etc. soit le plus rapide possible, donc en particulier qu'il n'y ait aucune latence entre l'accès à n et à n+1. C'est la raison pour laquelle je dis qu'il n'y a pas de meilleure façon de demander à accéder à 100,101,102,etc. que de les demander dans cet ordre. Donc que si les requêtes sont déjà triées, le TCQ ne sert à rien.
 

J'avais cru lire plus haut que le TCQ de Seagate en avait 256 mais peu importe
 

Non. Juste après avoir fini de lire le 8ième (secteur n°150), la tête et le DSP sont prêts à traiter immédiatement la 9ième (secteur n°151).
 

Pas d'accord. C'est tellement possible de réorganiser les accès aux secteurs à moindre coût qu'il y a au moins 3 algos différents qui le font dans le noyau 2.6. Ca ne coûte rien, tu ne réordonne pas les données elles-mêmes mais juste les pointeurs vers les données. 300 cycles à tout casser, et même pas 4ko de données en RAM pour 100 requêtes à réorganiser ...
 

Je regrette de paraître désagréable, mais j'ai beau retourner le problème dans tous les sens, je ne comprends toujours pas à quoi ça sert. Ca fonctionne peut-être très bien, mais ça ne sert plus à rien. Tout comme les cartes ISA de compression de données que vendait Stac à l'époque où compresser des données était coûteux en temps (aujourd'hui le CPU compresse du Zip à 5Mo/s).
 
 

Exact. Mais je pense que ces latences sont largement masquées (facteur 1000) par celles des disques ...
 

Je l'ignorais - lien ?
 

Il est un peu cavalier de balayer comme ça 12 pages de topic ...
 

Non. L'OS n'envoie que des requêtes triées au contrôleur, donc le TCQ n'a jamais à réordonner les requêtes, donc il ne fait jamais rien, donc il ne sert à rien.
 
 

Si tu fais un test bas niveau, forcément le cache aide. Maintenant la question est de savoir si, dans la vraie vie, il va jamais arriver que l'OS fasse des requêtes qu'il n'a pas trouvé dans son propre cache de 300Mo mais que pourtant le disque aurait bien au chaud dans son cache de 4 ou 16Mo ...
 

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: arrivera-t-il une seule fois que le TCQ réordonne les requêtes de l'OS qui arrivent toujours déjà triées ? ou que l'OS demande au cache intégré de 8Mo (150Mo/s) du disque ce qu'il n'avait pas dans son cache de 300Mo (4Go/s) ?
Je prétends que non. Sinon, je voudrais bien qu'on m'explique, avec un exemple, dans quel cas ça pourrait se produire.

Au passage lu sur la press release de Seagate:
 

Trop fort ...
 
EDIT: cela dit les 400Go ont l'air tentant, notamment les 8ms ...

--> A mon avi ils ont reajuster le temps d'acces moyen en prenant en compte le boost des NCQ ... la mecanique doit etre identique je pense... (a moins qu'il est reduit le diamètre des plateau aussi...)
 
--> Les NCQ sont plus efficace en environnement SMT et SMP oui...

bien vu pour l'article de storage reviews
 
Oui le NCQ est l'application du TCQ sur le sata avec un maximum de 32 requêtes simultané au lieu de 255 sur le TCQ (SCSI)
 
 
95mb/s environ pour un bon cache
 

--> Vu qu'il est bridé par le controleur ATA/SATA on saura jamais vraiment, mais vu que c'est de la SRAM ca doit etre plus que ça... Meme si le surplus de vitesse n'est utile que lors de traitement de reorganisation et pas vraiment pour le transfert de donnée..

 
Pas seulement au perfs, je parle de 7200tr/min et de plusieurs disques contre des DDYS (36mb/s maxi) actuelle qui sont trés proche en débits, certe les temps d'accés y sont aussi pour quelque chose
En mono disque certe l'ata avec des raptor seras un peu plus performant car plus directe dans la plupart des charge mais pas en surcharge continu
 

 
...
 

 
Je ne dit pas le contraire, cette ordre est bien le meilleurs
mais dans la pratique, certain que le TCQ sert
désactive le sur ta carte SCSI pour t'es deux 10K pour tester
 

 
255 pour le TCQ SCSI, 32 pour le NCQ
 

 
...
 

 
ce n'est pas la même chose bordel !
 

 
bah fait le test proposé plus haut
 

 
oh là trop vieux, désolé de toutes façon c'est pas resté
 

 
si tu veut
marre de me répéter et chacun sont opinion. c'est clos de mon coté
 

 
bah demande au gas de l'article si le TCQ et le cache sont utile ou non avec sont noyau et pourquoi il désactive certain algo en cas de TCQ, ça iras plus vite.

heu oui en interne c'est plus rapide, je parle juste du readburst

Je ne comprends pas ce que veux dire "supporter le multi-threading" pour un disque dur. Ou alors ils veulent dire que si deux applis accèdent respectivement à 101,..,110 et l'autre 201,..,210 et que les accès s'entremêlent en 101,201,102,202,... alors le NCQ va les réordonner lui-même ... Bah oui mais bon encore une fois l'OS les aura déjà réordonnées lui-même.

Je crois que ce que Glacote ne comprends pas que si l'OS demande les secteurs : 201 - 203 - 207 - 205 - 206 - 204 - 202 par exemple, ou bien les secteurs 201 - 202 - 203 - 204 - 205 - 206 - 207... Ca sera pas du tout pareil...
 
Cas sans NCQ : l'HDD fera les requetes dans l'ordre de l'OS... Le premier cas sera moins efficace c'est clair...
 
Cas avec NCQ : Les deux cas reviendrons au même... (cf paragraphe suivant)
 
Avec NCQ vs sans NCQ : sans NCQ, l'HDD traite les secteurs dans l'ordre de l'OS cad 201-->207... alors qu'avec NCQ l'HDD regarde où est le tete... Si elle est sur le secteur 201, ou avant, effectivement ca ira pas plus vite avec NCQ que sans...
Mais si la tete est sur le secteur 204 il commence pas celui ci jusqu'au 207... Et pendant ce temps d'autre requetes arrive... Il va donc repartir vers le 201, et si par magie y'a une secteur qu'il peut lire sur le passage, il le lira... Apres le cache sert effectivement a reorganisé tout ca dans le bon ordre et a l'envoyé au controleur ensuite.
Au final on pourrai avoir 204 - 205 - 206 - 207 - XX1 - XX2 - 201 - 202 - 203 par exemple... Chose que l'OS n'aurai pas pu prevoir.
 
Je sais pas si j'ai été assez  clair mais bon...

Disons que le NCQ favorise le multithreading quoi Enfin j'ai pris ca comme ca... Enfin eux parleny dans le sens, le NCQ est encore plus efficace en environmment multi threading...

Pas compris.
 

 
Il faudrait d'abord que je mette un noyau 2.6. Mais oui tu as raison il faut que je fasse le test. Ma carte est une "Adaptec AIC-7892A U160/m (rev 02)" sais-tu comment je dois procéder ?
 
 

Là on n'est pas d'accord
  Une bio, c'est une liste de bvec.
  Un bvec, c'est une liste de requêtes élémentaires triées,
  par exemple "[101,110] [237,245] [432,456]"
  Une "requête élémentaire" c'est une liste de numéros consécutifs de secteurs, par exemple "[101,110]"
Quel que soit l'ordre dans lequel les applications ont demandé ces secteurs logiques, le noyau va les demander dans l'ordre "[101,110] [237,245] [432,456]".
 
Le TCQ va convertir ces numéros logiques en secteurs physiques sur les plateaux, puis réorganiser tout ça afin de minimiser la latence. Je suis donc d'accord que ce n'est pas la même chose. Mais (je prétends que) ça n'a strictement aucune importance: le meilleur ordonnancement des secteurs 101 à 110 est de toute façon 101,102,103,...,110. Donc il n'y a rien à réordonner, que ce soit en termes de numéros logiques ou de secteurs physiques.
 
 

Tu as raison.
 
 

OK, merci de ta participation (no pun).
 

Il ne s'agit pas de "désactiver" mais de "choisir" un algo parmi plusieurs; les différences portent sur autre chose (mixage lecture-écriture, réactivité, etc.). Mais dans tous les cas les requêtes sont toujours triées.

Merci pour cette précision, je suis tout-à-fait d'accord avec toi. Ton mon argument se résume à dire: l'OS ne demandera jamais " 201 - 203 - 207 - 205 - 206 - 204 - 202" mais directement "201 - 202 - 203 - 204 - 205 - 206 - 207". C'est tout.

bon aprés une bonne respiration
 
si l'os demande les secteurs en simultané : 201 - 203 - 207 - 205 - 206 - 204 - 202
Le NCQ ou TCQ commencera par le plus proche secteur ou la tête est a un ce moment par exemple au plus prés avec un léger retour arrière : 203, puis 204 puis 205,206,207, 202, 201
et renvera à l'OS dans cette ordre 201 - 203 - 207 - 205 - 206 - 204 - 202 avec un temps d'éxécution en interne baucoup plus rapide que de la RAM
le tout sans temps morts pour ordonner.
 
il ne fait pas une requête une par une. Le TCQ permet du coup d'éxécuter plus rapidement la lecture de petit fichier simultanément
pas un groupement qui attends un moment
au final 8 fichiers seront lu plus rapidement en envoyant les 8 demandes simultanément qu'en l'envoyant une par une dans le bon ordre comme le fait le noyau.  
Il est bien indiqué dans la notice que cette fonction de lecture envoyé requête par requête ralenti le disque lorsque le TCQ est actif ou en raid Stripping hardware

Que l'OS reorganise ou pas, ca change presque rien avec les NCQ/TCQ... (Dans la théorie pure, apres faudrai analysé ca plus en profondeur...)
 
Pour moi la reorganisation faite par l'OS n'est plus trop cruciale avec les NCQ, meme si elle doit etre fait un minimum (du fait du nombre de requete mise en fille d'attente possible...)...
 
Quand a l'interet du cache, il suffit de fait 32x la taille d'un secteur d'un HDD recent avec NCQ, et là on saura la taille minimum qu'il faudrai a un HDD pour pouvoir faire du NCQ convenablement...

J'etait pas dans le faux donc..
 
De plus ce qu'il ne fait pas oublié c'est qu'un HDD est en general plusieurs plateau, plusieurs tete de lecteur Donc que le NCQ doit y faire attention, car y'a jusqu'a 6 secteur au meme emplacement des tetes...

Merci à toi de bien vouloir poursuivre cette conversation Comme je te l'ai répondu plus haut l'OS ne demandera jamais "201 - 203 - 207 - 205 - 206 - 204 - 202", en simultané ou pas. Plusieurs applications simultanées vont peut-être les demander dans cet ordre, mais l'OS, lui, demandera dans l'ordre "201-202-203-204-205-206-207". L'ordonnanceur des entrées-sorties (drivers/block/*-iosched.c) est écrit spécifiquement pour ça.
 

Oui, mais même si par exemple le dernier secteur du plateau du-dessus est par exemple le n°1000, alors le n°1001 n'est pas à l'autre bout de l'autre plateau, mais juste à-côté. Précisément pour éviter de tuer le débit si quelqu'un demande 1000,1001 d'affilée.
 
Encore une fois l'idée est que puisque je peux numéroter les secteurs comme bon me semble, je le fais de façon à ce que quand le les lis dans l'ordre (hypothèse retenue par la quasi-totalité des applications et des OS) il n'y ait aucune latence: l'ordre le plus performant pour accéder à des secteurs est l'ordre croissant. Après que ça veuille dire que la numérotation physique soit bizarroïde, peu importe.

Ca n'empeche que, sur un disque ATA, il peut y avoir jusqu'a 6 secteur a un emplacement de la tete, du coup le NCQ doit en prendre compte pour son optimisation...
 
Chose que l'OS ne peut connaitre... D'ou l'importance des NCQ pour allé encore plus loin dans l'optimisation...

Salut ...
 
Je compte me mettre au raid avec l'argent que je vais avoir cet été ...
 
Alors, je vous explique le truc : je voudrais avoir un système :
-rapide (plus que 1 seul disque)
-stable (pouvoir perdre un disque sans perdre les données)
-compatible linux
-SATA (c'est évolutif et ça prends moins de place)
 
...J'ai un pote qui a déjà tenté l'expérience :
->d'abord une Highpoint 1640 (4 ports SATA, raid5 soft mais il le savait pas) en raid5 4HDD 160Go ( 100% CPU + perfs de merde => renvoi dans la semaine ...)
->puis une Highpoint 1820 (8 ports SATA, raid5 hard) en raid5 toujours avec les 4HDD, là c'est nettement mieux (après les drivers beta fournis par highpoint) ... des perfs entre un raid0 2HDD et 3HDD (très bien, quoi...) il a niqué un HDD ça marche encore très bien (comme quoi, le raid5, ça sert ...)
(bon par contre, la 1820 est PCI64/66MHz, ça dépasse un peu, mais ça va, niveau vitesse, tout le reste est intégré à la CM et sur un autre bus PCI...)
 
...Bon par contre, sous linux ... c'est bof ... je m'explique :
On installe d'abord sur un DD IDE (pour pouvoir installer les drivers...), puis sur le raid5, en faisant un initrd car les drivers sont externes ... et ça marche ...
Mais par contre, pas moyen de tenir 2H sans planter ... et c'est à cause du contrôleur/driver ... donc c'est pas cool pour moi qui suis 90% du temps sous linux ...
 
Donc j'ai un peu regardé, et le TOP pour linux, c'est bien 3ware !!!
(1 driver unique pour la carte qui n'a pas changé depuis longtemps car pas besoin => très bon support linux, pas de driver spécial pour le raid, la carte s'occupe de tout... le pied, quoi...)
 
Niveau vitesse, pas de problème, j'ai un Bi-Athlon XP 2400+ (K7D-Master), j'ai donc des ports PCI64/66MHz   ... donc pas du raid0 ... mais plutôt du raid 0+1 (4HDD), ou bien, tant qu'à faire, du raid5 (3HDD)
 
Donc par contre, côté prix, ça fait un peu mal (465€ la carte, 8506-4 ou 9500S-4, d'ailleur, autant prendre une 9500S-4 !!)
 
J'ai regardé chez la concurrence ... il y a adaptec, mais c'est pas beaucoup moins cher ... et le reste, c'est pas très compatible linux ...
 
 
Donc je pense que finalement je vais prendre
-Carte contrôleur 3ware 9500S-4 PCI64/66MHz : 469€
-3 disques dur Hitachi 160Go SATA 8Mo : 3x107€=321€
 
...ce qui me ferait 320Go en raid5 ... mais pour 790€ ...
 
Si quelqu'un a autre chose à me proposer ... (j'ai encore 2 mois pour y réfléchir ...)
 
 
 
PS : à propos du NCQ ...
Si l'OS demande les secteurs 1000, 2700 et 5800 sur un DD, et que les disques ont chacun 2000 secteurs ... le NCQ va réordonner 2700-5800-1000 car ce sera plus rapide pour lui ... de plus, les têtes bougent en même temps que le disque tourne, donc il faut connaître l'emplacement PHYSIQUE des secteurs (ce que seul le contrôleur connaît)
 
(en espérant ne pas dire une trop grosse connerie   )

Je cite une réponse qui viens de m'être faite sur la LKML:

Mon post précédent (sur les bvec) n'était donc pas correct. Il fallait lire:
 - une queue est une liste ordonnée de requêtes
 - une requête est une liste de bio (ex. [101-110] [201-210])
 - une bio est une liste de bvec (ex. [101-110])
 - un bvec est (au plus) une page (ex. 101)
 - une page (mémoire) correspond à un secteur (logique)
 
Je recherche le lien adéquat concernant l'ordonnancement des requêtes.

Pas sûr (?), il faut tenir compte du temps de traitement. Et je pense que si c'est le cas, alors les secteurs les uns au-dessus des autres ont des numéros consécutifs, pour accélérer le traitement.
Es-tu t'accord avec l'hypothèse "l'ordre le plus performant pour accéder à une liste de secteurs est toujours l'ordre croissant" ?

bah logiquement oui

Je milite intensément pour le raid logiciel (attention, encore un topic-à-troll).
A base de simples Promise TX100 à 30? pièce et de disques parallel-ATA de base (un seul par nappe). Ca permet par exemple de faire un RAID par-dessus des pseudo-partitions cryptées au milieu de l'espace libre de vraies partitions FAT32, ou de faire du Raid6, ou de faire du RAID avec des disques de tailles différentes, de d'ajouter un disque à la volée, etc.
 

Je n'ai pas compris, pourrais-tu détailler ?
 

Des secteurs physiques contigus n'ont pas des numéros logiques consécutifs. En revanche quand tu as finis de lire le secteur logique n°10 quelque part sur le disque, la tête est pile-poil au-dessus d'un secteur ailleurs (peut-être sur un autre plateau) qui a le numéro 11. Justement pour que le n°11 soit accessible tout-de-suite.
 

Heureusement qu'on a encore le droit de poster pour dire de grosses c.....ies ...

comment t'explique qu'en fesant un graph des débit maximum d'un disque, le débits décroit jusqu'à la fin ?
 
si la fin du plateau supérieur est au centre du disque lorsque le plateau inférieur commence à être lu comme tu dit le débits remonterai et une courbe concave serait tracé au niveau d'un graph.
 
hors c'est pas se qui se passe, le secteur 1 est sur le plateau supérieur, le 2 sur le plateau inférieur, le 3 supérieur ainsi de suite.
Le secteur représente le "quartier" : n
secteur 2 est décalé logiquement décalé au n+1 selon la vitesse des plateau mais pas forcément juste à n+1 Pourquoi ? Que ce passe-t-il si un secteur est défecteux ? il est viré, dans ce cas le secteur 2 peu se retrouver à N+3 voir n+4, et même n+20 décalé vers l'arrière vis à vis du n.
sur tout plateau d'un DD sortie d'usine il y a des secteurs défectueux. on peu rien y faire, c'est ainsi. et généralement c'est toutes une zone du disques étendu sur plusieurs pistes.
les têtes sont solidaire entre elle donc juste aprés la lecture du secteur 1 à n, la têtes du plateau inf. se retrouve à n+1

Donc si l'OS demande une liste de secteurs déjà dans l'ordre, le NCQ ne sert à rien ? Après effectivement à moi de prouver que c'est toujours le cas ...

J'ai retrouvé le lien que je cherchais: introduction de Linux Weekly News au gestionnaire de périphériques à blocs dans le noyau 2.6:
l'architecture générale
les bio
request queues 1 et 2

(sur cette image le bvec n'est pas ordonné)

qu4est ki a rien a voir mais je trouve plu le topic ou ils causent de comment faire pr faire taire son hdd, et ou y a des exemples! merci de me rép j'ai qqch à leur montré! d'un vrai pro! du bricolage lol

Tu penses à ça ?

Ca depend le nombre de secteur, et etre dans l'ordre ne signifie pas non plus contigu de plus...
 
Sans compter qu'a l'instant T ou l'OS demande les secteurs, la tete peut etre n'importe ou sur l'HDD...
 
Le cas le plus critique serais le cas ou si on demande les secteur 1-2-3-4-5 et que le tete est le sur 6, et bien le NCQ sert a reordonné pour lire les secteurs 5-4-3-2-1 dans cet ordre...
 
Le NCQ optimise "dynamiquement" tandis que l'OS "statiquement"... Enfin c'est ma vision des choses.

 
non lol bel et bien au topic kil y a sur ce forum

Sur requests queues 2:

Les ordonnanceurs réordonnent donc les requêtes afin de maximiser les performances, sauf si l'OS demande explicitement le contraire.
Or c'est précisément le cas des systèmes de fichier journalisés (notons que si le NTQ matériel est malgré tout activé cela va violer la sémantique voulue par le système de fichier).

Non, précisément, mais la propriété "l'ordre le plus performant pour accéder à une liste de secteurs est toujours l'ordre croissant" est toujours vraie quel que soit l'agencement physique. L'agencement physique est en fait construit expressément pour qu'elle soit vraie.
 

Non car le disque ne change pas de sens de rotation ... Mais dans l'exemple ou la tête est juste au-dessus de 3, et que tu demandes 1,2,3,4,5  le NCQ va peut-être faire 3,4,5,1,2 (c'est pire a priori mais peut-être dans certains cas ...).
 
Je ne vois pas dans quel cas la position actuelle de la tête pourrait inciter à changer l'ordre de requêtes.
 

Sauf que l'OS a exactement les mêmes infos que le disque; et même beaucoup plus, en fait.

 
  c'est polémique de défendre le raid software. bon certe au niveau performances en bench c'est parfois meilleurs en raid logiciel, mais en utilisation de logiciels serveur/Pao/3d enfin bref qui bouffe de la ressource CPU/RAM/MASSE STORAGE le raid hardware est carrement plus rapide. Pour du Raid0 ou 1 c'est pas cata en software, mais le 5  
Le raid soft me semble surtout viable pour des niveau de raid complexe  
enfin tout dépends de ce qu'on en fait.
 

 
exemple trés judicieux ! sur des lectures de secteur complétement étalé sur les plateau.
Ce qui est souvent le cas d'ailleurs en utilisant un logiciel==> lecture fichier, lecture du swap, lecture des dll
 
une autre remarque : windows met souvent un bout du fichiers swap vers le début du disque puis au milieu alors qu'entre deux il aurait pu mettre le swap en contigü.
 
y'a pas grand chose à expliquer c'est une question de balayage des têtes sur la surface des plateau
 

 
et non pas forcément voir explication de mon post précédant
 

 
bah ça arrive à tout le monde certe, mais au moins j'ai apprît des trucs et clarifier le peu de connaissances acquises dans ce domaine

bon merci de me répondre. topic pr rendre un hdd moin bruiant personne sais????

Activer l'AAM je vois que ca
Et la les perfs s'effondre (sauf sur Seagate qui a prevu son HDD pour fonctionner avec l'AAM d'activé...)

Tu as raison. L'organisation des secteurs est: 1 secteur sur une face, le suivant sur l'autre face du même cylindre à l'endroit où se trouve la tête (suite à la rotation du disque), et ainsi de suite. Mais (il me semble que) l'hypothèse "l'ordre le plus performant pour accéder à une liste de secteurs est toujours l'ordre croissant" reste vraie.
 
Je ne sais pas comment sont alloués les secteurs défectueux, mais je crois qu'ils sont mis au bout de chaque zone (la surface d'un disque est découpé en "zones" de débit constant), et non pas au milieu des vrais secteurs. Parce qu'en général quand un secteur est défectueux ses voisins (physiques) le sont aussi (poussière, crash de la tête, etc.).
 
J'ai complètement ignoré ce problème dans mon raisonnement; je présuppose que c'est trop marginal pour influer (du moins tant qu'il n'y a aucun secteur défectueux).
 
 

J'avais prévenu que c'était un autre de mes "topic-à-troll" ...
 

Bah je ne suis pas d'accord. Etant donné un poste de travail qui fait de la PAO, oui c'est sûr, mais maintenant moi pour moins cher que ta carte RAID je monte un petit serveur NFS/smb indépendant auquel tu branches ta station. En plus niveau fiabilité des données c'est mieux (séparation des pannes poste de travail/serveur, etc.).
 
Bref ça me fait rire de voir des cartes RAID IDE à 450? alors que pour ce prix tu as boîtier+alim sérieuse + 3 cartes Promise + Athlon 1.8GHz + 1Go DDR-SDRAM + 2 cartes GigabitEhthernet ... A part pour économiser de l'électricité ...

Quelques infos sur les systémes de fichiers et adressage physique
 
FAT :

 
===> Arf, l'OS ne connait pas par avance l'adresse physique suivante, par contre il peu ordonner les numéro de clusters. qui généralement lorsqu'il ne sont pas fragmenté, sont contigu, donc l'ordre croissant est le meilleurs cas.
fragementé, le clusters suivant est généralement l'un des suivant, mais pas toujours, l'os Anticipe en choisissant l'ordre croissant qui semble donc le meilleurs. mais c'est pas forcément le cas, le clusters suivant peut trés bien se retrouver avant le n°1 parcequ'ils n'y a plus une place contigü suffisante sur les secteur aprés
suffit de regarder un défragmenteur opérer pour ce rendre vite compte que les bout de fichiers sont éparpillé aléatoirement et que ce n'est pas un cas rare.
 
NTFS:

 
 
là aussi l'emplacement physique est connu par le pointeur sauf si le fichier à l'attribut résident"
 
 
A propos du formatage bas niveau :

OK, la FAT c'est complètement pourri.
 

Voilà un vrai système de fichier.
 
Si c'est pour dire que quand on accède à un fichier, les secteurs logiques correspondants ne sont peut-être pas contigus, fort bien. Mais ça n'a rien à voir; ça veut juste dire que la couche "système de fichier" va demander à la couche "pilote de disque dur" des secteurs dans le désordre. En revanche le pilote, lui va les mettre (dans l'ordre) dans sa liste des requêtes en attente. Lorsque le scheduler décidera traiter cette liste de requêtes, il les exécutera donc dans l'ordre.
 
EDIT: je n'ai jamais dit que chaque fois qu'on accédait à un fichier on demandait des secteurs dans l'ordre. J'ai juste dit que quelle que soit la couche qui demandait des secteurs (système de fichier, gestion du swap, sur-couche RAID1, etc.), ses demandes seraient déjà triées (par la couche "pilote du disque dur" ) avant d'être envoyées au disque dur. Qu'elles soient contigues ou pas est une autre question (pour laquelle le NTQ n'est d'aucun secours puisqu'il ne va rien réordonner puisque tout est déjà trié).
 
 

Tout-à-fait; ça doit bien faire 10 posts que je dis que les secteurs de numéros consécutifs ne sont pas contigus sur le disque. cf par exemple le dernier. Ce qui n'empêche pas (au contraire) que quand j'ai fini de lire le secteur physique de numéro logique 10, le secteur physique qui se trouve sous la tête a comme par hasard le numéro 11.
 
Es-tu d'accord ou pas finalement avec cette phrase: "l'ordre le plus rapide pour lire les secteurs logiques de numéros de 100 à 110 est de les demander dans cet ordre: 100,101,102,...,110".

 
Merci beaucoup pour les infos, par contre ce que je ne saisis pas bien c'est que si je monte des dd en raid0, je ne pourrais pas créer de partition ????

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