raid5 de raid5

[alpacou]

je profite éhontémént de l'occasion pour m'instruire.

sachant que le raid est destiné à stocker et enregister de l'audio, plurôt de gros fichiers (entre qqs mo et plusieurs centaines) en mutipstes, le travail étant généralement plus important en lecture qu'en écriture :

pour optimiser les performances (vieille baie compaq ra4100 , controleur tout aussi vénérable raid ra4000 fcal) comment configurer le cache, entre 0% lecture/100% écriture et l'inverse ?

pour l'instant je l'ai laissé à la valeur par défaut : 50/50.

autre sujet de questionnement : la taille des bandes ...

là encore j'ai laissé la valeur par défaut à savoir 16ko (16/32 ou 64 ko possible).

j'ai constaté ces valeurs pour le raid 5 ou 4, alors que pour la raid 0 ou 10 c'est : 64/128 ou 256 ko .

à quoi cela correspond il et quelle incidence sur les performances ont ces réglages ?

[nicodache]

bein si la lecture est plus importante, associe lui plus de cache
ensuite, les bandes, ou stripe en anglais, sont simplement la taille de données à partir desquelles on calcule

à savoir que tout ce que tu veux enregistrer sur ton raid sera découpé en bouts de 16k.

l'indice, est la perte d'espace dans le cas de fichiers trops petits pour le stripe, et le gain de performances vu que tu calcules moins pour plus de données, si tu as un stripe plus grand

comprendu ?

[dsebire]

c'est pas tout a fait ça....
tu confonds avec la taille des clusters nico. mais tu as raison dans le sens ou si il utilise des "gros" fichiers, il faut mieux mettre une taille de clusters elevée.

apres pour la taille des stripes ya plusieurs ecoles.
le stripe est la taille de base qui est lue/ecrite sur chaque disque. si tu stripe est de 16ko et que tu as 5 disques, tu auras des blocs de données de 16*(5-1)=64ko (5-1 a cause du RAID5)
les puristes disent qu'il faut matcher la taille des blocs avec la taille des clusters au moment du formattage. bien evidament, ça ne focntionne qu'avec un nombre impair de disques.
ça s'explique avec le fait que de toute façon windows ou n'importe quel OS lira forcement un cluster complet donc autant en profiter pour que ça coresponde a la taille de bloc. en lecture/ecriture sequentille ça ne change rien. par contre en cas d'acces aléatoire et surtout de Read/modify/write, tu y gagne beaucoup car tu lis le cluster windows le modifie et tu l'ecris sans avoir d'autre besoins de calcul au niveau de la carte RAID puisque le bloc est claculé directement.

l'autre cas c'est de mettre une taille de stripe assez faible de maniere a ce qu'il n'y ait jamais plus d'un cluster windows dans un bloc (rappel un bloc=taille de stripe*nb disque-1).
ça limite les calculs Xor lorsque tu modifie un cluster (les blocs sont lus/ecrits dans l'integralité sauf le dernier ou le premier mais les calculs sont limités car bloc petit)

le pire des cas (ce qu'il ne faut pas faire):
bloc monstrueux 64k*(6-1 disque)=320ko
cluster petit 4ko
a chaque fois que tu vas ecrire un cluster sur le disque et bah faut calculer la parité sur 320ko au lieu de 4..... coté efficacité, c pas terrible tu imagines bien

[alpacou]

houlla c'est du lourd... :d

pour la taille du cache mémore du contrôleur y a il un rapport avec le cache en écriture du disque sous windows, les tweak d'xp pour l'audio préconisent de le désactiver; mais c'est peut être sans rapport.
donc privilégier le cache en lecture pour le contrôleur et pour windows mettre 2048, voire 4096ko comme taille de clusters, mais :

concernant les stripes :

j'ai 12 disques dans l'array 64k*(12-1)=704ko donc taille de cluster de 1024 sous win => pas plus d'un cluster par bloc

puis je néanmoins mettre 2048ko comme taille ou est ce sans intérêt ?

[dsebire]

avec 12 disques, je te conseille plutot d'en mettre 11 dans l'array et un en hot spare (la probabilité de perdre un HDD est quand meme assez elevée
tu auras donc 10*64=640ko. le problème c'est que sous win, la taille max des clusters est 256ko en NTFS5.
donc ça va pas passer.
resultat: si tu prends un cluster de 128k ton stripe sera de 128/10=12.8 donc 8 (arrondi a l'inferieur)
si tu prends 4, ça sera encore mieux 4*10=40 donc un clusterrentrera sur a peu pres 3 blocs et comme les blocs seront assez petits, tu auras peu de perte au niveau des calculs sur le chevauchement

[IvanleFou]

dsebire c'est le baron de raid

[chili69]

oula pas que du raid !! c'est une encyclopédie

[dsebire]

merci les gars

[alpacou]

avec 12 disques, je te conseille plutot d'en mettre 11 dans l'array et un en hot spare (la probabilité de perdre un HDD est quand meme assez elevée
tu auras donc 10*64=640ko. le problème c'est que sous win, la taille max des clusters est 256ko en NTFS5.
donc ça va pas passer.
resultat: si tu prends un cluster de 128k ton stripe sera de 128/10=12.8 donc 8 (arrondi a l'inferieur)
si tu prends 4, ça sera encore mieux 4*10=40 donc un clusterrentrera sur a peu pres 3 blocs et comme les blocs seront assez petits, tu auras peu de perte au niveau des calculs sur le chevauchement tu peux expliquer, je comprend vite quand on m'explique longtemps, 4

attends attends, je décroche là, je ne suis pas du métier hein

déjà w2kserveur ne me permet de formater qu'en 64k de taille d'unité d'allocation (cluster c'est ça ?) max.

[dsebire]

cluster de 128k
stripe de 4ko*10 disques (12-1 hotspare -1 parité)
donc bloc de 40ko donc un cluster rentre sur 4blocs (3 entiers + petite portion d'un autre)
le chevauchement c'est quand tu ecriras le 2eme cluster sur l'array.
le premier cluster sera sur 3+portion blocs, le second remplira la fin du 4eme bloc + 2 cluster entiers + portion 7eme bloc etc.....
le truc interessant ça se passe sur le 4eme bloc. tu as une petite partie du 1er cluster et le debut du 2nd
lorsque tu ecris le premier cluster, tu as le droit d'ecrire directement les 3premiers blocs mais pas le 4eme (il contient un morceau du 2nd cluster)
resultat, tu dois d'abord lire le 4eme bloc (donc calcul XOR), le modifier dans le cache de la carte controleur (le debut du bloc avec la fin du 1er cluster), calculer la nouvelle parité XOR et enfin ecrire sur le disque ce bloc (avec un XOR de verif).
resultat au lieu d'une parité, tu en calcules 3.
c'est pour ça qu'il faut que la taille des blocs soit assez petite (tu calcules autant de parité mais sur moins d'octets)

compris

[alpacou]

euh, en théorie (théorie, pays merveilleux car en théorie tout fonctionne)

cluster max 64k,... pas taper

stripe de 16ko*4disques (array de 5 disques => dont 1 de parité + 1 spare * 2 arrays)

d'où taille de block de 64k = taille du cluster, elle est pas belle la vie ?

oui mais je perd 4 disques

alors si je bourrine car je radine : cluster 64k avec bloc de 160ko (stripes de 16ko*10) enpratiqueil y aura une grande chutte de perf en lecture docteur ?

[dsebire]

si tu fais 2 array, tu peux te permettre de ne pas mettre de hot spare. avec un peu de chance, si ya 2 disques qui tombent, ils seront dans 2 grappes differentes.
donc tu auras 2 array de 6 disques (5 + 1 de parité) donc tu n'en perds plus que 2 cad autant qu'avec uen array de 12 disques avec un hot spare

je te laisse refaire les calcul, on verra si t'as tout saisi

[alpacou]

je veux bien calculer si tu me dis comment je fais pour pouvoir formater avec des clusters de 256k, chez moi ça s'arrête à 64k. :d

[dsebire]

calcules avec 64ko

[c0bw3b]

Au passage, ca me fait penser à quelque chose tout ça : Explication des différents RAID
C'est en anglais, et comme c'est le site d'un fabricant y'a systématiquement des liens vers leur matos. Mais bon ca reste assez intéressant.

[dsebire]

dans le meme style, en plus complet et sans pub (dsl )
http://www.storagereview.com/guide2000/ ... ingle.html

[c0bw3b]

Ah oué d'accord, je m'incline..