Petite question sur la CM Asus A8N-SLI Deluxe

[Morbid069]

le Raid 0 sur un système dédié à un usage aussi varié que celui d'un utilisateur lambda est tout aussi efficace que de conférer à un autobus les perfs d'une formule 1, pour s'exprimer de façon optimales, à chaque utilisation il correspond un striping (16....128 qui n'est pas supporté par tout les contrôleurs).....ces paquets sont définis à l'initialisation du Raid pour toute la capacité des disques groupés, et le partitionnement qui intervient plus tard sur un ensemble de 500 Go n'arrangera rien au niveau des perfs.....

je pense que je n'ai aps tout compris tatar tu peux reepliquer stp ... C'est pas que j'ai pas compris mais quel strping (16 ... 128) pour quel utilisation ? et si ona un disque de tres grande quapacite (500Go dans se cas) il vaut mieux un striping en 128 ?

merci

[K-Lee]

Comment dire... 2, 4, 8, 16, 32, 64,128 et 256 K ce sont comme de petits containers qui fonrmeront l'ensemble de la FAT de ton DD.

Imagine que tu as un stripping de 16 K, tous les containers sur ton DD auront une capacité de 16 K, si tu copies un fichier de 100 K, il occupera 7 containers, soit 7 * 16 K = 102 K, tu perds donc 2 K, parce que 2 fichiers différents ne peuvent occuper le même container.

Maintenant un stripping de 128 K, le même fichier de 100 K occupera tout le container de 128 K, tu perds donc 28 K, puisque le même container ne peut être occupé par deux fichiers différents.

La subtilité réside donc dans le type de stripping qu'on va utiliser en fonction de l'utilité du RAID, des petits plus lents mais mieux pour des petits fichiers et la perte de place ou des grands, plus rapides mais où on perdra beaucoup d'espace, un fichier d' 1 K prendra à lui seul un container complet de 128 K, donc 127 K de perdu.

Fais les propriétés d'un ensemble de fichiers, tu verras qu'ils auront deux valeurs, la taille réelle et la taille sur le disque, vu qu'il prennent plus de place que leur taille effective en raison des pertes par container.

Pour un OS, 32 K ou 64 K, pour un serveur d'images, 256 K.

Par exemple...

[tatar33]

La valeur du stripe ne dépend pas de la capacité du disque mais de l'utilisation visée, si l'appli sollicitée nécessite le transfert (l'écriture ou la lecture) de gros fichiers, utilisation : audio, vidéo...etc une découpe à 128 est la bienvenue, si l'appli fait appel à de nombreux enregistrements ou données de petites tailles l'accès en mode aléatoire sera optimisé par un striping en 16 ou 32, certains modules de prog de jeux, navigation Internet, bases de données...le 64 faisant figure de compromis entre ces 2 modes....n'avantageant personne mais pénalisant le moins.....

[squallix]

Il y a un truc pas logique dans ce que tu dis.

Tu dis que tu as un Hitachi Sata II, mais qu'il est branché en UDMA133, ce sont deux technologies différentes, le UDMA ce sont des nappes plates de 80 fils ou aussi appelées IDE et le Sata II ce sont des fins fils

Voilà un cable IDE UDMA 133

Voilà un cable Sata I ou II

moi il me semble que j'ai ces deux types de cables, mais c'est quoi ces histoires de raid0 etc ??? c'est quoi la meilleur config pour tirer le mieux de son HD ? et comment faire ?

[tatar33]

Le Raid 0 n'est pas une histoire mais un conte:

Il était une fois, des aventuriers de l'informatique et de l'électronique qui étaient très ennuyés, les disques durs, alors disponibles sur le marché, étaient non seulement de petite capacité mais leurs performances étaient comme leur taille : réduites.

Ils eurent alors l'idée de les grouper, pour additionner simplement leur capacité, ainsi venait de naître le JBOD, acronyme de Just a Bunch Of Disks, un simple bouquet de disques, qui ne possédait comme avantage que de fournir une plus grande capacité de stockage, sans augmenter les perfs.

Le domaine dans lequel s'exerçait leur talent était celui des serveurs, il fallait maintenant faire en sorte que les disques durs répondent le plus rapidement possible aux multiples requêtes en encombrant le moins possible le réseau..

Et si, pour gagner du temps, dit le plus malin, on imaginait que l'écriture des enregistrements se faisait simultanément sur les disques, on tronçonne les données en paquets et on les envoie en même temps sur les disques, en toute logique, l'écriture d'un fichier sur 4 disques devrait prendre 4 fois moins de temps que sur un seul disque, non ?

Ainsi fut-il fait, le Raid 0 venait de voir le jour..

Hélas, les serveurs, comme chacun sait, sont des bêtes de travail donc soumis au stress et à la fatigue, en cas de panne de l'un des disques, adieu la base de données, toutes les données étaient perdues, il fallait réinitialiser l'ensemble raid, recharger la dernière sauvegarde et perte des dernières modifications ou création d'enregistrements.

Et si, pour sauvegarder les données, dit le plus prévoyant, on faisait une copie simultanée de ce groupe de disques en Raid 0 sur un autre groupe de disques, en cas de panne il suffirait de changer le disque défectueux par sa copie !

Le plus fort en math (surtout en Stat) et très économe de surcroît, vit de suite que cette solution quoique séduisante allait coûter bonbon.

Et si, au lieu de copier l'intégralité des données sur le groupe de disques de secours on inscrivait de façon codée les caractéristiques de chaque morceau de fichiers, leur contenu, leur emplacement etc. en cas de panne ces informations comparées aux morceaux intacts permettront de reconstituer le fichier en entier..Ce génial radin venait de mettre le doigt sur le contrôle de parité.(comme on peut le trouver sur les barrettes mémoires en SDram par exemple, qui fonctionne sur 64 bits soient 8 groupes de 8 bits, on ne rajoute que 8 bits pour la parité : 1 bit par groupe).

La princesse ne se réveilla pas pour autant, mais la famille des Raid du type 1 et consorts vit le jour dans l'indifférence du peuple abasourdi et incapable de s’offrir de tels contrôleurs et de tels disques, le SCSI qui servait d'interface à tout ce joli mode était (est tjrs) hors de portée de leur bourse.

Ce n'est qu'un conte, pas une fable donc pas de moralité....