Reprise du message précédent :
fdisk n'est pas compliqué, pas plus en mode secteur (fdisk -u /dev/sda par exemple, avec un raid 0 semi hard, c'est plus un truc genre /dev/mapper/pdc_xxxxxxxx)
utilise Gparted, il est capable de gérer beaucoup de controleurs semi hard
 
voilà donc les bonnes valeurs :
 
lettre | capa | 1st sector | last sector
 

 
C*H*S -1 : tu multiplie les valeurs de géométrie de ton raid et tu soustrait 1 pour avoir le n° du dernier secteur de l'avant dernier cylindre (ça doit ressembler à xxxxxx/255/63 avec xxxxxx d'environ 60000 pour le nombre de cylindre, valeur à récup' soit dans fdisk (mais avec 1 pour h ou s, c'est pas ça), soit dans ton setup raid)
 
windows n'utilise jamais le dernier cylindre d'un disque ou d'un raid, car celui ci est souvent incomplet

Hum, pour être franc, là je ne comprends pas vraiment...

En fait, c'est seullement les n° absolus des secteurs de début et de fin de chaque partition, à indiquer à fdisk (attention, fdisk linux, pas le vieux fdisk DOS), c'est à quel niveau que tu coince ? ^^

C:   10Go       256 ->  20.971.775
D:   300Go     20.971.776 -> 650.117.375
E:   150Go     650.117.376 -> 964.690.175
F:   40Go      964.690.176 -> C*H*S -1

Je ne sais pas ce que représente ce qui est en rouge...  

Puis c'est tout nouveau pour moi et j'aime pas faire à l'aveuglette, faut que je comprenne tout c'que je fais (en un mot: chiant)

oui c'est compréhensible, moi non plus j'aime pas bosser à l'aveuglette ^^
 
c'est les numéro des secteurs : premier secteur de la partition et dernier secteur de la partition, pour chaque partition. Le travail au secteur pret, c'est très précis, et partitioné avec fdisk, l'alignement est parfait sans erreurs possibles du moment que le calcul est fait correctement.
 
pour le calcul en question :
 
pour déterminer le premier secteur de la première partition : je prends le nb de secteurs par strip (chunk size de 128ko = 256 secteurs par strip)
l'espace non partitioné en début de disque va donc du secteur 0 au secteur 255 (ce qui fait 256 secteurs)
 
la partition système commence donc au secteur 256
 
pour savoir où commence la partition qui va suivre :
 
je fais 2^(30-9)*10 + 256 = 20971776
 
2^(30-9) :
30 : on veut indiquer des Go (2^30 octets)
9 : taille d'un secteur : 512 octets (=2^9)
 
*10 : pour une partoche de 10Go
 
+256 : décalage : ce qui doit être laissé avant la partition (soit pour l'alignement, soit parque les secteurs précédents sont déjà destinés à une autre partition)
 
le secteur 20971776 est le premier de la 2eme partition, et donc, le secteur précédent, le 20971775, est le dernier de la première partition
 
ensuite, 2^(30-9)*300 + 20971776 = 650117376 : c'est donc le premier secteur de la 3eme partition
 
...et ainsi de suite, je t'épargne l'achat d'un stock de piles pour caltoche scientifique ^^
 
comme je prends 1Go=2^30 octets, pas de pb, c'est un multiple de 512, donc même en créant partitions sur partitions, ce sera toujours aligné si on ne laisse pas de secteurs libres entre 2 partitions.
 
etc...
 
 
jusqu'au dernier secteur de la dernière partition, qui doit être le dernier secteur de l'avant dernier cylindre (on est bien d'accord que cette histoire de cylinder/head/sector est totalement logique et ce n'est pas la géométrie réelle du volume logique, ce n'est rien d'autre qu'un méca d'adressage, rien de plus)
bref, en multipliant le nb de cylindres (C) par le nombre de piste par cylindre (H) par le nombre de secteurs par piste (S) et qu'on retranche 1 , on retombe pile poil sur la valeur à indiquer pour le dernier secteur de la dernière partition.
 
tu contatera que les premier secteurs de chaque partition sont toujours pairs, et les derniers, impairs
 
je ne pense pas que tu trouvera ce genre de truc sur le net, car les admin de bdd mysql server qui à la base ont fait de l'alignement avec des windows server, ne s'amusaient pas à complexifier les choses en usant de plusieurs partitions, et ils ne devaient pas non plus se sentir à l'aise avec des outils linux, pourtant vachement plus puissants, sans compter que les docs qu'on retrouve ont souvent des incohérences/imprécisions/abus de langage. Bref,  j'ai du mettre au point ma méthode en partant de la simple théorie =p , just for fun, et aussi parceque j'ai des raid 0 à la pelle  
Il y a aussi eu des histoire d'alignement avec les OS hyperviseur VMware type ESX, mais c'est révolu, ESX aligne tout seul à présent, vista et server 2008 aussi, w7 je suppose aussi
mais win 2000/2003/XP : oui là il faut encore aligner manuellement.
 
dernier truc pour fdisk : les flags pour une paritition NTFS : 0x07, et 0x0c pour une FAT32

Merci T3K, j'ai à peu près compris, faut juste que je me représente tout ça via un graphique. J'ai envie de bien assimiler pour éviter d'faire une connerie  

Voilà l'architecture :

Bon, je ne suis pas encore vraiment sûr pour les valeurs  

Edit1 : Heu, en regardant le schéma de plus près, je me demande si les partitions E et F ne devraient pas plutôt se trouver dans STRIP UNIT 1...? Et dans STRIP UNIT 2 y-aurait comme un "miroir" de ma table de partition présente dans STRIP UNIT 1, puisque les fichiers seront tantôt copiés d'un coté, et tantôt copiés de l'autre... Arf, je cherche trop là, j'vais dormir !

C'est quoi tes strip unit ? pourquoi tu as représenté de l'espace libre d'alignement entre tes partitions ? (alors que j'ai fais les calculs pour faire un alignement seullement en tout début de disque, tout le reste est aligné)
Pour ta partition Program files, met carément des cluster de 32ko.
 
La table de partition, tu en as une seulle, dans la mbr, c'est le premier secteur de l'array. Et des strip, tu en as un peu plus de 3.800.000 pour l'ensemble de tes 2 disques.
N'oublie pas  le controleur RAID 0 se contente de dispatcher les données entre les 2 disques, modulo le chunk size, il ignore tout de ce qui sera écrit dessus, c'est pas son problème ça, la table des partitions, les partitions, les fs, il s'en fout de ça, il fait son boulot point. ça après c'est l'OS qui gère, à bien plus haut niveau.

J'ai changé le schéma, ça me semble plus juste comme ça :
 

 
C'est correct ?  
 
Ensuite pour les strip unit c'est une façon de visualiser le disque coupé. Puis, Les espaces d'alignements c'était une manière pour moi de comprendre que :
 
 
256 = début de C:  |  20.971.775 = fin de C:
20.971.776 = début de D:  |  650.117.375 = fin de D:
650.117.376 = début de E:  | 964.690.175 = fin de E:
964.690.176 = début de F:  | C*H*S -1 = fin de F:
 
J'ai donc voulu représenter ça schématiquement. C'est bien ça ?

En fait non, désolé mais si tu veux représenter par un schéma, ça ne ressemblera pas à ça ^^
le strip unit est une vision erronée de la chose (à moins qu'il ne soit bien alterné entre les 2 disques, mais le truc c'est qu'il faudrait éviter de les faire se suivre parceque c'est un coup à se planter), l'autre truc qui m'étonne, c'est que j'arrive pas bien à piger comment tu fais entrer 16ko de données dans 2 clusters de 4ko, 'faudra que tu trouve une bonne explication  
Le truc c'est aussi, sur ce shchéma, c'est qu'on ne sait pas si les cluster sont écrit en mileu de strip, ou sur le bord d'un strip, dans le 1er cas, les clusters seront, concretement, en supposant qu'il soient consécutifs et que le fichier n'est donc pas fragmenté, tous sur le même disque, dans le second, les 4 clusters de 4ko seront réparti entre 2 disques, soit avec 1 sur le disque 1 et 3 sur le disque 2 (soit l'inverse : 3 sur le hd1 et 1 sur le hd2), soit 2 sur chaque disque. Bien sur dans la réalité tu as en plus la fragmentation qui vient s'en mêler, ça n'arrange pas les choses.
 
ensuite, je ne vois pas pourquoi tu duplique les partitions, ça n'a pas de sens en RAID, pas même en raid 1 (il duplique les blocs et c'est transparent). Surtout qu'en RAID 0, la tolérences aux pannes c'est 0... si un disque te lâche, tu perd tout, et comme toutes les données sonts hachées menues par bandes de 128ko réparties entre les 2 disques (voire plus pour certains raid 0). C'est pas comme un JBOD qui consiste à concaténer 2 disques, là les accès sont totalement fait en alternance, sinon l'allignement n'aurait absolument aucuns sens, mais je suppose que tu as déjà vu tout ça avant de te décider à te lancer dans le montage d'un RAID 0. Enfin il me semble que tu as pigé le truc, mais que le pb c'est qu'on a une représentation complètement différente de la chose.
Bref, pour faire simple, il faut déjà savoir quel niveau tu veux représenter, déjà savoir si tu veux représenter les disques physiques (ce qui n'a aucun intéret en terme d'organisation) ou le disque logique, le LV, ce que tu vois au final dans ton gestionnaire de disque ou dans diskpart ou dans fdisk....
 
Il ne faut pas mélanger, sortir "fichier" et "raid" dans la même phrase n'a pas de sens, car ce sont des choses de niveaux différent. En fait pour bien faire, il faudrait faire un diagramme en couche, comme pour modéliser les couches en réseau, ici idem, en gros pour simplifier t'aurais :
 

 
explication : les données utilisables sont écrites dans des fichiers, les fichiers sont écrits et lu dans un système de fichier, les système de fichiers sont mis en place dans des partitions (sauf exception linuxienne ultra bourin dans certain cas), les partitions sont définie sur des disques (soit physiques, soit logique -LV : logical volume-, dans le cas de raid c'est un disque logique), les disques logiques sont basés sur le controleur de disque RAID, le controleur trouve l'espace utilisable sur des disques (bel et bien physique ce coup ci)
 
rien que là, on a 7 niveaux, 2 niveaux qui ne se touchent pas n'ont pas grand chose à voir, alors tu vois que c'est pas facile à shématiser  
 
le niveau le plus bas que tu pourra voir au travers d'un OS, ce sera celui que j'ai affublé du 5/
dans le cas du non RAID, de l'utilisation simple d'un disque, tu peux considérer que le controleur ne fait pas de raid et se contente de présenter directement le contenu du disque tel quel à l'OS. (en gros dans ce cas on retrouve exactement la même chose en 5/ et en 7/, le controleur ne fait pas de tour de passe-passe comme en RAID)
 
'faudra que je fasse un schéma concret quand même.
 
bref, tout ça pour dire qu'au final, représenter un raid ou un disque simple, ça donnera exactement la même chose sur un schéma, la seulle et unique chose qui va apparaître en plus, dans le cadre d'un alignement, c'est que tu fait, avant la première partition, un décalage de 65 secteurs (soit 32.5 ko), espace inutilisé dans le but d'aligner les structures des système de fichier (clusters dans le cas de windows) des partitions avec les strip RAID (ainsi, tu n'as pas de cluster placés "à cheval" sur 2 disques, alors que su un raid non aligné, tu as tous les x clusters (x dépendant du cluster size et du chunk size, par exemple toi dans le cas de ta partition système avec des cluster de 4ko sur ton raid avec des strip de 128ko, tu as x = (2^(17-12)) = 32 donc un cluster sur 32 qui est basé sur un secteur de 512 qui va déborder sur un strip de l'autre disque), un cluster qui à le cul entre deux chaises si tu me permet l'expression   ), ce qui oblige le système à faire plus d'I/O que ce qui se fait sur un raid aligné. Concretement, sur le shéma, chaque partiton n'apparait qu'une seulle fois, tu n'as pas de strip unit (mais tu peux représenter, ou pas, 3800000 (un peu plus même, j'y vais à la louche là) de zones de 128ko, alternées entre disque 1 et disque 2 : ce sont les strip), et une seulle bande verte de 32.5ko pour l'alignement juste avant le première partition, et juste avant cette bande verte un autre bande de 31.5ko qui n'est jamais jamais utilisée sur un disque (ou RAID) basé sur un partitionement mbr classique comme on sait en faire depuis... très très longtemps. (en tous cas je ne devais pas être né le jour où c'était un truc tout nouveau   )

Ah donc, quand les données sont réparties suivant le strip, et en supposant l'écriture d'un fichier de 4Ko, 1Ko peut s'écrire sur le hd1 et 3Ko sur le hd2, ou alors autrement mais ce n'est pas forcément symétrique ?

Je pensais qu'il fallait compter en puissance, du coup, 16Ko de données, pour moi, c'était réparti à deux endroits de 4Ko puisque 4^2 = 16...  Bon apparemment, 16Ko c'est à la limite 8Ko par ci et 8Ko par là... Sans oublier que ce n'est pas symétrique et qu'il peut copier 12Ko par ci et 4Ko par là, bref, je ferai pas toutes les combinaisons... C'est bien ça ?

Mais, on est bien d'accord que là, la seule valeure que l'on peut changer et donner à chaque partition c'est la grandeur des clusters ? Concernant le strip, y-en existe qu'une seule c'est soit celle donnée par défaut (chunk size) soit celle qu'on aura envie de d'indiquer ?

En fait, j'ai dupliqué la partitions car j'aurai aimé voir comment le strip découpe les fichiers. C'est vrai que j'ai à peu près compris le fonctionnement mais j'ai une fâcheuse tendance à tout vouloir schématiser, grr. (j'adorais les frises chronologiques à l'école !)

Jai bien compris que tout ça était un empilement, un peu comme les poupées russes, c'est vrai que représenter ça par un dessin c'est pas simple, mais ça peut se faire, juste à partir de la création du raid=volume logique=array, histoire de bien voir, au premier coup d'œil la différence entre cluster, strip, alignement.

quand tu dis : (mais tu peux représenter, ou pas, 3800000 (un peu plus même, j'y vais à la louche là) de zones de 128ko, alternées entre disque 1 et disque 2 : ce sont les strip)

Là je ne comprends pas; tu veux dire que le strip se contente "d'installer" des zones de 128Ko (ou celles que l'on aura indiqué l'or de la création du raid (striping size)) alternées entre disque 1 et disque 2 ? On aura donc, sur une capacité de 500Go, des strip de 128Ko qui occuperont tout l'espace ?

Puis concernant l'alignement, d'accord on indique le nombre de secteur, avant la première partition, en fonction du strip, mais on doit faire ça pour chaque début et fin de partition ? Car les calculs que tu m'as gentillement fait concernent bien le nombre de secteur, du début et de la fin de chaque partition ?

j'espère que je paraît pas trop lourd avec toutes mes questions...    

Edit1 : J'ai refait ça :

les clusters sont représentés par les barres verticales de couleurs verts clairs. Ensuite le strip est représenté par le contour noir de chaque cluster, enfin, pour bien visualiser le rôle du strip, j'ai simulé l'écriture d'un fichier de 64Ko sur la partition C:, le résultat est représenté par les barres verticales de couleurs bleues.

Là j'y suis ? allez, dis oui...    

Je crois que tu compliques TOUT...
 
En gros tu crees un array de taille correspondant a la taille du disque dur le plus petit fois le nombre de disque dur (raison pour laquelle on prend en general des disques de meme taille)
 
Ensuite tu choisis un stripsize 128 ko... tu choisi la taille que tu veux mais 128 ko c'est enorme...
 
Une fois l'array cree tu fais tes partition comme bon te semble...voila...

 
ça c'est vrai aussi, les meilleurs résultats c'est plus autours de 32ko.
 
Dans le cas d'un RAID 0 (ou 4 -obsolète-, 5,6, 1+0, 0+1), enfin tous les raid où tu as des strip, dont les niveau combinés
 
Tu l'utilise exactement comme un disque ordinaire, après si tu veux alligner (on va dire que ça rentre dans la catégorie création des partitions), tu fait un tout petit décalage au début, une seulle et unique fois, avant la première partition, après si toutes les tailles de toutes les partitions sont un multiple du chunk size (tu te base sur 1Go, soit 2^30 octets, soit encore 2^21 secteurs de 512 octets, ensuite qu'il y en est 10Go ou 300Go c'est pareil), alors ce seul décalage suffit puisque que la position de la première partition alligne d'office la 2eme comme il faut et ainsi de suite, c'est aussi simple que ça l'alignement, ça consiste juste à corriger le décalage des partitions par rapport aux strip....
C'est juste un simple problème de math, les strip ne sont pas des structures, c'est un concept abstrait : c'est tant de secteurs consécutifs accessible séquentiellement sur un disque donné (en gros)  

Oui, j'ai bien compris tout ça, mais pour l'alignement, tu m'as bien donné des valeurs pour chaque début et fin de partition ?
 
Sinon, mon schéma est vraiment faux ?

Je n'ai pas donné des valeurs d'alignement, ce n'est pas un décalage, j'ai donné, pour chaque partition, le secteur de début, et le secteur de fin, c'est des valeurs absolues. C'est le fait d'utiliser ces valeurs, qui font que les partitions sont alignées.

Ben ui, c'est bien ce que j'ai compris, un peu comme ça :
 

 
?

ok, si les bandes vertes sont les secteurs de début et fin, là oui c'est tout bon ^^
 
pour c*h*s-1, tu va devoir faire le calcul (multiplication prioritaire =p ), à partir des valeurs inscrites dans fdisk, je vais faire un petit screen pour ce dernier point.
 
edit :
(le temps de refaire 37 tables dans un serv' mysql et je passe à l'explication   )
 
edit2 :
 
souligné en :
 
jaune : fidsk -u :commande à taper pour avoir fdisk en utilisant des unités secteurs (et non cylindres), /dev/sda : disque, dans le cas d'un raid matériel, c'est comme pour un disque simple, pour un raid semi hard (c'est ton cas), c'est un chemin dans le genre /dev/mapper/pdc_xxxxxxxxx avec 9 lettres aléatoires, bref tu tape le pdc, puis : complétion (avec [tabulation]) et l'id va s'inscrire tout seul.
 
en bleu : C
en rouge : H
en vert : S
en rose : nombre total de secteurs utilisables sur le disque (ou le raid), attention ceci compte aussi le dernier cylindre, souvent incomplet, et windows n'aime pas trop...
 
dans l'exemple : un cylindre fait 255*63 = 16065 secteurs soit 7,844 Mo
le dernier cylindre fait : 12582912 - 255*63*783 = 4017 secteurs, soit 1.961 Mo, il est donc incomplet
 
pour trouver le dernier secteur que windows daignera utiliser sans causer de problème : 255*63*783 -1 = 12578894
tu remarquera que fdisk, en mode cylindre (j'avais créé les partoches en mode cylindre sur la machine de l'exemple), s'est bien arrêté à ce même secteur et n'a pas utilisé le cylindre incomplet en fin de disque (qui va du secteur 12578895 au secteur 12582911)

Merci T3K    
 
Bon, je m'obstine mais je pense que cette fois, ça ressemble à ça :
 

 
 
Donc j'ai recommencé à simuler l'écriture d'un fichier de 64Ko sur la partition C:. C'est représenté par les clusters bleues. C'est bien comme ça que ça fonctionne cette fois ?
 
En fait : strip/cluster Ko=nombre de cluster ?
 

bon, voilà un schéma rapide, du début d'un volume RAID (les 512 premiers ko), un pixel de large = 512 octets
sauf à la fin, le zoom : un pixel = 128 octets
 

 
 
Les 4 1ère lignes, représentent les strip, dont je fait varier la taille (16k, 32k, 64k, 128k, les tailles courrantes)
les strips en noir sont en face des blocs lus/écrits sur le 1er disque, et les strips en rouge, sur le 2eme disque (le schéma se limite à 2 disques)
 
ensuite, les 4 lignes suivantes représentent le début du volume RAID, on y voit seullement le début de la 1ère partition, on va dire que c'est une partition NTFS (la MFT se situe à peu pret au milieu de la partition, et d'ailleurs, sa taille rentre aussi en compte dans l'espace occupé, bref la MFT est à considérer comme un fichier)
les 4 denières lignes sont juste un agrandissement (x4)
 
couleurs :  
gris clair : espace non utilisable pour le partitionnement
rose : secteurs inutilisés (pour faire l'alignement)
vert : clusters des systèmes de fichiers (2 couleurs pour distinguer)
et en rouge, partie d'un cluster située sur l'autre disque (seullement sur l'agrandissement), en fait dans ce cas précis, un cluster utilise un bloc sur un disque et les 7 autres sur l'autre disque
 
respectivement :
 
1/ Raid non aligne / partition avec clusters de 4ko
2/ Raid aligné pour un chunk size de 16, 32 ou 64 ko / partition avec clusters de 4ko
3/ Raid aligné pour un chunk size de 128 ko / partition avec cluster de 4ko (ton cas)
4/ Raid aligné pour un chunk size de 32ko / partition avec cluster de 32ko (typiquement ce que j'ai naturellement tendance à faire, sauf pour une partition système où là, il n'y a pas le choix)
 
la mbr est dans le trait noir de gauche
 
Après voir si les clusters son utilisés ou non par le fs, c'est rien de plus que du coloriage...

Merci T3K, en fait c'est un peu plus précis que mon schéma, le miens était plus simplifié, mais j'avais bon aussi ^^
 
Mais t'es bien d'accord pour dire que :  
 
strip/cluster Ko=nombre de cluster ?  
 
Mais je n'arrive pas à comprendre que le le nombre de cluster dépend du strip, j'ai plutôt tendance à penser que ça dépend de la partition directement.  
 
Quoi que, je vois les strip comme des tiroirs d'une commode. Dans ces tiroirs (strip) se trouvent des boites (cluster) du coup; si je veux ouvrire une boite, forcément je suis obligé d'ouvrir le tiroir, là, deux choses peuvent arriver :
 
- Plus le tiroir (strip) est grand, plus je pourrai ouvrir de boîte avant d'avoir besoin d'ouvrir un nouveau tiroir, donc là, j'augmente mon débit en lecture séquentielle
 
- Plus le tiroir (strip) est grand, plus je mettrai du temps à compter le nombre de boîte, voir celle qui sont vide et celle qui contiennent la bonne information. pas très pratique : là je perds de la latence et du débit en aléatoire (enfin ça peut être compensé en H24 par le gain de débit en séquentiel car un fichier est rarement découpé totalement )  
 
Pfiout, j'suis vraiment lourd
 

 
 
Tu te poses trop de questions, prends des parametres standards polyvalent pour la plus part des fichiers...au final tu verras aucune difference...t'espas en train de nous monter un serveur pro avec des milliers d'acces...etc...

glopp, je me doute bien que tout ça ne va pas doubler les perfs, mais je pense quand même que ça vaut le coup.
 
Enfait, j'ai arrondi à 2.500.000 clusters de 4Ko pour une partition de 10Go. Donc, avec un strip de  128Ko, on aura 32 clusters Dans le strip ? Donc en gros, on aura 32 clusters de 4Ko dans 78125 strip ?
 
Si c'est bien ça, le strip crée plusieurs partitions dans une partition ?  on en revient aux tiroirs de la commode.  
 

Clairement en usage reel tu verras aucune difference...

Et surement qu'en bench tu verras une difference de genre 4 mo/s sur un debit de plus de 200 mo/s... ah oui quand meme 2 % ca vaut la peine... :-)

Oui c'est vrai que pour ce type d'usage, c'est pas vraiment notable, il y a un léger mieux dans les gros transferts mais ça s'arrête à ça, les temps d'accès des disques ne diminuant pas...
 
à la base, ça servait pour les grosses bases de données avec beaucoup  d'accès simultanés, moi j'ai mis ce genre de truc en place pour des solutions de virtualisation basées sur windows, avec plusieurs 10aines de VM en fonctionnement simultané (mais maintenant, c'est plus trop le cas, les hyperviseurs type ESX / ESXi c'est mieux au niveau des perf' des VM), après l'alignement avait de l'intéret dans le sens où je mettais les disques de VM sur un système de fichier dont les clusters faisaient exactement la même taille que les strip, donc à la fin sans alignement je me serait retrouvé avec un serv' dont la totalité des clusters de ce système de fichier auraient été à cheval entre 2 strip, vu le nombre d'accès aléatoire du à l'activité des VM, ça commençais à faire lourd, le moindre accès à un cluster donné soliciterait systématiquement 2 disques sans alignement, c'était des petites VM (une seulle appli par VM), mais elle utilisaient leurs disques quand même, et les disques des VM ne sont autre que des fichiers dans un système de fichier dont les perf' dépande fortement de comment il a été monté.
 
Au niveau de la mesure des perf', bien entendu, les test du type HDtach' ne montreront aucunes différences (vu qu'il teste directement sans passer par les fs), par contre avec des test genre ATTO, qui teste le système de fichier, là tu aura une mesure des performances réelles au niveau des écritures de fichiers.

Ok, bon je passe à la pratique. Je commence par mettre 32Ko de strip sous mon raid, car là, par défaut il me l'a mis à 128Ko. Mais c'est grisé, faut que je trouve un moyen pour pouvoir y toucher...
 
Raid0 [500Go] Strip 32Ko
 
C: Partition primaire NTFS Windows XP [10Go] [cluster 4Ko]
D: Documents and Settings [300Go] [cluster 32Ko]
E: Program Files [150Go] [cluster 32Ko]
F: Incoming [40Go] [cluster 32Ko]
 
Western Digital [160Go]
 
* Partition Principale ;
 
G: Partition Swap [5Go] [cluster...?]
H: Partition pour Backup [155Go] [cluster...?]

Partition swap useless mais au cas ou tu t'en fait une faut la mettre en tete de lecture avant le systeme, et pour la taille des cluster je dirais 4 Ko egalement. Mais honnetement tu perds ton temps.
 
C'est sur quel controlleur que tu veux faire ton RAID ? ca me semble louche qu'il ne te laisse pas le choix du strip size. Si tu as deja fait ta grappe RAID faut la casser et la refaire avec un strip size de 32 Ko

En fait, avec glopp tout est useless, c'est cool la vie ? Non, it's useless !
 
J'comptais juste balancer le swap sur un disque dur à part du système, donc au tout début d'la partoche.  
 
Pour le raid c'est intel ICH10R, je me suis peut être gouré dans le pilote, mais si j'arrive à accéder à la configuration du Raid, c'est qu'c'est bon. J'vais, comme tu dis glopp, le casser puis le refaire.

Bah disons que le swap sur un autre disque ca a eu paye...mais si le disque en question est plus lent que le disque en RAID je vois pas l'interet...
 
Ton raid va passer son temps a attendre le swap que tu auras mis sur  l'autre disque... autrement dit : si il est vrai qu'en lecture ecriture ton RAID 0 etre rapide...il va se trainer des que te fera usage d'application qui font massivement appel au swap...autrement dit, tout le temps...

Bah oui il sera forcément plus lent puisque ça n'est qu'un disque, mais étant donné que le swap sera sur la toute première partition, je me dis que meme face à un raid, ça peut le faire, non ? Sinon je peux le mettre sur le raid, mais juste après la partition système...

oui juste après la partition système de 10Go, c'est pas un problème, tu reste quand même sur le début de ta paire de disque, le débit normalement ne baisse pas encore à ce niveau là, par contre il va faloir revoir le partitionnement pour replacer une partoche de 5Go sur le raid (et si tu compte réaligner, refaire les caluls, mais ça reste rapide à faire)

Bon bah si c'est mieux d'faire la partition swap sur le raid, alors ok, mais j'ai déjà 4 partoches principales...

Alors dans ce cas il faut faire 3 partitions principales et une étendue, avec 2 lecteurs logiques dans l'étendue. Après le tout est de savoir sur quelle partition tu prends les 5Go pour faire ta partition swap

 
C'est jutement cette question qui m'intrigue    
 
Je pense mettre le swap sur une partoche étendue...? Tout de façon, je ne vois pas vraiment de différence entre une partition principale et étendue, mis à part que dans cette dernière on y attribue un certain nombre indéfini de lecteurs logiques.  
 
Après, j'me demandé, NTFS ou FAT32 ? Je sais que dans une partition  NTFS, la copie de la  MFT se trouvant en plein milieu, cela fragmenterait le fichier de swap en 2 parties, ce qui n'est pas bon au niveau performances. Donc FAT32 ?

oui le swap il est préférable de le mettre sur une partoche FAT32
 
si tu fais une partition étendue, ce sera très certainement la 4eme, hors tu dois mettre le swap en début de disque (ou plutot, de raid), donc juste après la partition système, donc il vaut mieux le faire en tant que partition principale. donc en gros, les partitions de 150 et 40 Go seraient en fait des lecteurs logiques dans la partition étendue. Quant aux 5 Go, tu peux les piquer à la partition de 300Go.

Arf, ça m'embête un peu d'mettre les partoches de 150 et 40Go dans des lecteurs logiques, quoi que, après tout, si les perfs sont les mêmes qu'en partition principale, ça me va.
 
Raid0 [500Go] Strip 32Ko
 
Partitions Primaires
 
C: Windows XP [10Go] [cluster 4Ko] NTFS
D: Swap [5Go] [cluster 4Ko] FAT32  
E: Documents and Settings [295Go] [cluster 32Ko] NTFS
 
Partitions Etendues
 
F: Program Files [150Go] [cluster 32Ko] NTFS
G: Incoming [40Go] [cluster 32Ko] NTFS
 
Western Digital [160Go]
 
Partitions Primaires
 
H: Partition pour Backup [160Go] [cluster 32Ko] NTFS
 
Voilà. Comme me l'a conseillé glopp, la partition swap pourrait être mieux avant la partition système ? Ou c'est pas la peine ?

ça complique beaucoup trop les choses de la mettre avant, windows risque de poser encore plus de problèmes, c'est bien plus simple de la mettre juste après, vu la faible taille de la partition système, c'est pas vraiment gênant.
 
Au niveau des perf', le fait d'utiliser des lecteurs logiques ou des partition principales n'a pas d'impacts
 
Pour la partoche swap, je te conseille de mettre des cluskters de 32ko
 
par contre sur le disque western de 160Go, t'es pas obligé de mettre des clusters si gros pour son unique partition, 4Ko maximum.

Ok, alors c'est parti pour ça :
 
Raid0 [500Go] Strip 32Ko
 
Partitions Primaires
 
C: Windows XP [10Go] [cluster 4Ko] NTFS
D: Swap [5Go] [cluster 32Ko] FAT32  
E: Documents and Settings [295Go] [cluster 32Ko] NTFS
 
Partitions Etendues
 
F: Program Files [150Go] [cluster 32Ko] NTFS
G: Incoming [40Go] [cluster 32Ko] NTFS
 
Western Digital [160Go]
 
Partitions Primaires
 
H: Partition pour Backup [160Go] [cluster 4Ko] NTFS
 
 
_____________________________________________________________________________________________
 
 
Alignement :
 
Début C:64 ------------- Fin C:20971583     (2^(30-9)*10 + 64 (-1))
Début D:20971584 ------ Fin D:31457344     (2^(30-9)*5 + 20971584 (-1))
Début E:31457345 ------ Fin E:650117184   (2^(30-9)*295 + 31457345 (-1))
Début F:650117185 ----- Fin F:964689984   (2^(30-9)*150 + 650117185 (-1))
Début G:964689985 ----- Fin G:1048576064  (2^(30-9)*40 + 964689985 (-1))
 
J'espère que c'est ça ?
 
 
 Alors création du raid (en trouvant un moyen de pouvoir "toucher" à mon strip puisque il est toujours grisé) Ensuite l'alignement sous fdisk et les partitions sous Gparted pour pouvoir changer les clusters, puis formatage, c'est bien l'ordre ?

attention pour l'alignement, il va faloir que je vérifie avec fdisk pour voir ce que ça donne, je ne me pas amusé à le faire sur des partitions étendues, je vais tester donc, mais à priori il devrait y avoir un décalage supplémentaire pour les lecteurs logiques. (Au passage tu as fais une erreur de calcul pour le début de la 3eme partition, la méthode pour ne jamais se gourer : la formule sert à chaque fois, à partir d'un secteur de début, à calculer le secteur de début de la partoche suivante, et à la fin quand tu connais tous les secteurs de début, tu fais -1 pour les secteurs de fin, aucuns risques de s'enmêler les pinceaux comme ça). Maintenant il reste à voir si il faut faire un alignement des lecteurs logiques à l'intérieur de la partition étendue...
 
Tu as bien cassé ton raid pour le refaire ? dans ce cas alors c'est pas normal de ne pas pouvoir changer de chunk size (128ko c'est vraiment trop gros), c'est quoi comme controleur ?

Ah oui, j'me suis trompé, d'ailleurs j'aurai dû m'en apercevoir puisque le début de chaque secteur  est paire, alors que la fin est impaire :

Alignement :

(2^(30-9)x(partition en Go)+(secteur de début)

Début C:64 ------------- Fin C:20971583    
Début D:20971584 ------ Fin D:30957343    
Début E:30957344 ------ Fin E:649617183  
Début F:649617184 ----- Fin F:964189983
Début G:964189984 ----- Fin G:1048076064 (-1)

Justement, j'me posé aussi la question quant aux partitions logiques.

Oui, j'ai bien cassé  mon raid. Mon controlleur est le ICH10R

Comment as-tu déterminé la fin de la dernière partition ? je suis assez sceptique sur le calcul, je parie que le secteur calculé est situé au delà de la limite... 2^21*40 - précédent n'est pas le bon calcul dans ce cas.
 
Il faudrait que je regarde le comportemen des lecteurs logiques dans la partition secondaire, le truc là c'est que ma bécanne test est en train de décompressé des fichiers en nombre extrèmement grand (+ de 50000), et j'en ai encore pour 5 bonnes heures.

Ah oui, c'est vrai qu'avec la fin de la dernière partition je vais devoir faire le calcul  à partir des valeurs inscrites dans fdisk et en me basant sur la formule : C*H*S -1, donc :
 
Début C:64 ------------- Fin C:20971583      
Début D:20971584 ------ Fin D:30957343      
Début E:30957344 ------ Fin E:649617183  
Début F:649617184 ----- Fin F:964189983  
Début G:964189984 ----- Fin G: C*H*S -1
 
Pas évident de trouver des infos sur l'alignement en général, mais alors sur l'alignement des lecteurs logiques encore moins, t'es ma meilleure source