Reprise du message précédent :

Par essence un strip ne peut pas être fragmenté.
 
J'ai peur de ne pas tout comprendre, mais point de vue SGF il y a une totale abstraction. Par conséquent la fragmentation dont nous sommes conscient reste celle que l'on aurai dans la cas d'un disque dur seul de même capacité que la grappe RAID courante.
 
Néanmoins, nous sommes sur que cette fragmentation soit en corrélation avec la fragmentation physique. En effet lorsqu'il est ordonné à la grappe RAID d'écrire un secteur N, il correspond a un secteur physique réel. (pour rappel un secteur en PATA/SATA c'est 512 octects)
 
Il ne faut pas mal interpréter le Strip Width. Le Strip Width définit à quel rythme l'on va changer de disque physique lors de la répartition des secteurs. C'est à dit que si la Strip Width est de 2 ko, soit 4 secteurs, nous aurons comme correspondance:

 
Mais à l'instar d'un disque physique, un secteur d'une grappe RAID correspond TOUJOURS un seul et unique secteur physique. Je ne vois donc pas comment il y aurait plus de fragmentation en RAID...

 
Désolé, la prochaine fois je préviendrai avant

 
Tu fais des backups sur d'autres DD déjà ?

Et pourtant... autant je suis daccord pour dire qu'il faut toujours regarder d'un oeil méfiant les nouveautés, autant je trouve que tu réfutes un peu facilement. Les contructeurs proposent, avec ces disques spécifiques pour particuliers, un mtbf doublé (passant de 600000h à 1200000h) et un taux d'erreur aléatoire non-recouvrable divisé par 10 (passant de 1sur10e14 à 1sur10e15, comme un scsi de base. un bon scsi est à 1sur10e16), ce qui leur permet d'être en conformité avec les normes de fiabilité de classe d'entreprise (dans le bas de la fenêtre de tir, il est vrai). Rien de spécial, donc ?!?!
Mais ma digression sur ces hdd "renforcés" n'était qu'une illustration hors-sujet.
 

Que tu raisonnes en statique ou en dynamique, tu ne peux empêcher les recours plus nombreux à la table d'allocation présente physiquement sur le volume en raid-0 que ce soit pour référencer la ou les différentes positions des stripes qui composent le fichier, en dynamique, ou bien pour attribuer des références de segments prédéfinis à des fichiers, en statique.
A mon sens, pour l'écriture, dans tous les cas tu te retrouves dans la situation où tu dois référencer les fichiers par petits morceaux (stripes) au fur et à mesure de leur délivrance par le contrôleur, avec le recours plus important à la table d'allocation que cela implique par rapport au flux, sur un single, d'un fichier ayant conservé son "intégrité" et dont les positions référencées seront uniquement fonction de la fragmentation du disque.  
Par ailleurs (aparté), en statique : tu prends aussi un risque de corrompre au-moins partiellement la table si tu as une panne de courant pendant l'écriture, je vois pas ce que ça aurait de spécial... C'est juste la faute à pas de chance.

Bien sur que si, le strip c'est le segment, il est évidement fragmenté dans le cas où il ne peut être écrit d'un seul tenant. Ceci dit, c'est plutôt rare dans le cas d'un strip, c'est dans la continuité des adresses physiques du disque, constituant l'ensemble des clusters ayant accueilli les segments, que l'on retrouve le plus souvent la fragmentation.  
C'est le cluster qui ne peut pas être fragmenté.
 

 
Ben, je l'ai expliqué plus haut. Je n'ai pas du être clair ou alors il y a confusion sur les termes utilisés. Pour être bien sur que l'on utilise les mêmes termes, je décris ceux ci en français et anglais ci dessous.
Unité de découpage pour répartition sur disques en raid : Segment - Strip
Plus petite unité adressable d'un disque - secteur - Sector
Plus petite unité d'occupation sur un disque - Unité d'allocation - Cluster(nombre entier de secteurs)
Partie d'un fichier non entier - Fragment - Fragment
 
Pour le reste, je pars du principe que ceux qui suivent la discussion savent comment est découpé un DD en 3D avec ses notions de plateau / Piste / Secteur en horizontal et Cylindre en verticale.

Maintenant, prenons l'exemple d'un fichier de 1 000 Ko à spliter sur 2 DD en raid 0.
- Cluster à 4ko (soit 8 secteurs)
- Segmentation à 128ko.  
Soit une segmentation prévue pour 32 clusters
Soit 1000k/128ko = 7,8 soit 8 segments de 32 clusters chacun.
 
Le fichier est découpé en segment de 128 ko, les segments à numérotation pairs seront écrits sur le DD1, les segments à numérotation impaires sur le DD2.
La segmentation est une notion logique qui se traduit par une écriture sur des clusters contigus du DD.
Ensuite ne perdons pas de vue, que l'objectif d'un raid 0 est la performance, donc le saucissonnage est réalisé dans cette optique de performance et donc en temps réels.
Ce qui signifie que chaque segment est écrit sur le DD à la volée à une adresse permettant de le recevoir sans fragmentation.
Et c'est comme celà que s'inscrit le segment 1 sur le DD1 (il en va de même pour le segment 2 sur le DD2) à l'adresse que nous nommerons ADR1(qui correspond en fait à l'adresse physique du premier secteur du premier cluster issu de l'écriture sur le DD du premier segment).
 
C'est au tour du segment 3 qui doit être écrit sur le DD1. Son positionnement est par défaut sur l'adresse physique suivante stockée dans la MFT: ADR2 := ADR1+32(cluster).
Et c'est là que se pose le problème, si cette adresse n'est pas libre ou l'espace insuffisant et ne peut acceuillir le segment, il y a fragmentation.
 
Donc comme on parle de segment de 128ko, le risque est faible mais pas inexistant. Il est plus important si on ne fait pas régulièrement de défragmentation.
Ce problème n'existe pas sur un disque seul parce qu'à l'écriture d'un fichier, l'allocation d'un espace suffisant à la reception de celui-ci est recherche en MFT. Ceci est rendu impossible en raid 0 parce que le principe de perfomance recherché et basé sur la segmentation rend impossible cette opération.
 
Bon, ceci dit, je le répète, le problème est suffisament rare pour être anecdotique sauf si on ne défragmente pas régulièrement ses dd.

Je crois sincerement que tu vois pas comment fonctionne en pratique le RAID. Tu cherches compliqué, alors que le RAID, niveau 0 en l'occurence, ne fait rien de bien sorcier.
 
Pour faire vite, et j'éditerais plus tard mon premier post pour utilisé le vocabulaire que t'as explicité plus haut. Le controleur RAID ecrit bettement, sequentiellement sur les disques. Cepandant le prerequis pour beneficier du debit double est de lire ou ecrire des secteurs qui sont sur les deux disques, donc dans le pire des cas la taille du Strip Size.

 
  Euh , c'est le fonctionnement pratique que je viens de détailler, pas le fonctionnement théorique ...    

Dire que le fragmentation est d'autant plus dommageable avec le RAID d'accord, mais dire que le RAID provoque la fragmentation : non !
 
Il est impossible d'imaginer que le RAID entraine un comportement different vis à vis de la fragmentation puisque pour le SGF c'est transparent.

Ce n'est pas le raid en soi qui provoque la fragmentation, c'est le processus de segmentation qui a été mis en oeuvre de cette manière.
 
J'y peux rien si c'est comme celà que ça fonctionne.  

Tu parles de table d'allocation de fichiers !!! Le RAID n'en a pas conscience, tout comme le SGF n'as pas conscience que c'est une grappe RAID.
 
Dans ton exemple, que ce soit un disque seul ou une grappe RAID, que le Strip Width soit 128Ko ou 32Ko, il n'y aura fragmentation que si et SEULEMENT si il n'y a pas assez de cluster contigus libre.
(c'est le job du SGF de savoir ça et de choisir où placer les données sur le disque dur)
 
Pourquoi diable dans ton exemple le 3e bloc de 128Ko serait fragmenté Soit le SGF n'as pas pu trouver un espace de 1000Ko libre, soit il les as trouvé et ils seront effectivement libre, soit il ne les as pas trouvé, mais RAID ou pas c'est au niveau du SGF que tout se passe.

Ce n'est pas un problème de fragmentation d'un block, c'est un problème de fragmentation dans la continuité des clusters. Dans mon exemple, le 3 ème bloc ne sera pas fragmenté mais sera placé ailleurs sur le DD et pas à partir du cluster suivant. On a donc fragmentation de la partie du fichier écrite sur le DD1.
J'ai un peu de mal à voir ce que tu ne comprends pas là dedans.
 

Mais c'est là le hic. Il n'y a pas physiquement un espace de 1000ko de libre constitué de clusters consécutifs puisqu'en raid on est sur plusieurs DD !!
Alors, c'est vrai que lors de la création de la partition, l'adressage logique laisse apparaître des adresses consécutives, mais cet adressage logique est une chose, la position physique sur les DD en est une autre. Ce que tu peux voir comme une chaine d'adresses consécutives de cluster n'est qu'une vision et n'est en fait qu'une représentation logique de la chaine. Physiquement, l'adressage est différent, et c'est logique puisque le fichier est éclaté sur 2 DD.
Si les têtes de lecture/écriture ne se déplacaient que sur le schéma de la représentation logique de la partition, alors tu aurais entièrement raison.

Le SGF raisonne que d'un point de vu "logique" par rapport a ce que le contrôleur disque lui renvoi.
 
Après, RAID ou non, effectivement physiquement c'est rangé un poil différemment.
 
Mais je te garantie que 1000ko successif de la grappe RAID = 1000 / n ko successif sur chaque HDD de la grappe RAID. Ce qui résulte au fait qu'il n'y a pas de fragmentation tant logique que "physique".
 
Alors si ça te plait, crois que le contrôleur RAID fait des truc compliqué, qu'il se gratte la tête 30 ans avant de savoir où ranger les donnée. Mais si c'était vrai, on aurai des performance 10x inférieur en RAID que sans...

 
Je ne vois pas pourquoi tu tournes la discussion à la dérision, elle était intéressante, c'est dommage.
 
Ce n'est pas une question de ce qui me plait ou non. J'ai essayé de détailler le plus clairement possible le mode de fonctionnement, maintenant, je ne peux rien faire de plus.
 
Et je suis pas d'accord avec ce qui est en gras, sinon il n'y aurait aucune raison de segmenter, il suffirait de scinder en plein milieu le fichier à copier et demander l'écriture en parallèle des deux moitiers sur les 2 DD, et ainsi on n'aurait plus à se faire ch.er avec des segments.
 
Maintenant, il m'est difficile d'aller plus loin dans mes explications.
 
Remarque : Si d'autres n'ont pas compris mes explications, c'est que je n'aurai pas été assez clair. J'aurai pourtant essayé de prendre le temps de le faire.  

Moi j'ai pas compris, et a priori je suis d'accord avec MEI.
 
Si on segmente c'est pour augmenter les perfs, si t'as une moitié du fichier sur un DD, et l'autre sur l'autre, alors t'as rien gagné en perfs, tu liras pendant la moitié du temps sur un disque et pendant l'autre moitié du temps sur l'autre.

J'ajouterais, qu'ayant fait 2-3 recherches sur Storage-Review hier au cas où.
 
En fait plus le Strip Width est petit, plus le debit augmente en moyenne, car plus souvent l'access concerne des bloc repartis sur plusieurs HDD de la grappe RAID. Cepandant, plus le Strip Width est grand, plus le temps d'access temps a etre bas, car une bonne implementation du RAID0 ordonneras en meme temps aux differents HDD membre de la grappe RAID d'acceder aux données voulus. Ce qui resulteras au fait que plusieurs données seront accédée en parallèle si une ou plusieurs d'entre elles ne sont pas répartir sur plusieurs HDD. Ce qui arrive plus souvent lorsque l'on a un gros Strip Width.
 
Je pense pas avoir forcement été clair. Faudrait que je fasse des graphiques pour illustrer ça. C'est prévu ce week-end...

ça montre que sauf utilisation spécifique de l'array, il faut une taille moyenne

 
bah, ca prouve que j'aurai perdu mon temps à essayer de l'expliquer.
 
Si vous pensez que la segmentation abouti à une écriture de clusters toujours contigus, ben libre à vous ...  
 
Après tout, cette discussion intéresse très peu de monde, je ne vais pas me mettre la rate au court bouillon.  

Je vais relire tes posts pour voir

En fait c'est ça que je comprends pas :
 

 
Dans quel cas cette adresse n'est-elle pas libre ?

 
Si un des clusters est déjà occupé par un autre fichier. On essaie d'écrire le segment 3, mais au moment où le segment 1 est écrit il est impossible de savoir s'il y a suffisament de place pour y loger consécutivement tous les autres segments impairs.
C'est le problème de l'écriture à la volée. Je ne dis pas que celà ce produit fréquement, je dis que ce cas existe.

Je pense que d'ici Lundi maxi, avec mes petits dessins je reussirais sans doute mieux a representé ce que je veut dire.
 
Ca sera plus simple.

 
En gros d'après toi il y aurait une fragmentation qui serait invisible de l'OS ?

Non, le SGF ne peut pas ne pas avoir cette information. Je dis qu'à la réservation de l'espace, cette réservation se fait sur la taille d'un segment, et segment par segment.

Ah OK, je comprends mieux.
 
Après je ne suis pas convaincu que ce soit vrai. Il m'a toujours semblé que le RAID0 était invisible du SGF, donc l'histoire des segments toussa il n'est même pas "au courant".
 
Au fait SGF = FS on est d'accord ?

Le SGF n'est pas exactement le FS.
 
Dans un système d'exploitation, il y a le système de gestion de fichier (SGF) qui est la couche d'abstraction entre le système d'exploitation et le système de fichiers. (ce qui permet à un OS de pouvoir gerer plusieurs système de fichiers de façon transparente)
 
Enfin bref, ça ne change pas le fait qu'à ce niveau, RAID ou non, le fonctionnement ce veut identique :
 
- Le système d'exploitation doit écrire TOTO.TXT. Ce fichier fait 32Ko, soit 64 blocs physiques.
- Le SGF recois l'ordre. Il doit ecrire sur C:\TOTO.TXT. C'est une partition NTFS avec des clusters de 4Ko. Il recherche donc 8 clusters contigus de libre.
- Le pilote de stockage de masse reçois l'ordre d'ecrire sur les 64 blocs physiques correspondant aux 8 clusters contigus.
 
Cas 1 : Nous ne sommes pas en RAID
- Le disque dur recois les commandes, les reordonnes comme il le souhaite et les executes.
 
Cas 2 : Nous sommes en RAID
- Le pilote/controlleur RAID (suivant l'implementation) sépare les blocs "logique" concerné de la grappe RAID en fonction de leur appartenance physique et envoi les commandes à chaque disques comme pour le cas 1.

C'est là où on est pas d'accord, il ne s'agit pas de "64 blocs physiques" mais "64 blocs logiques". A ce niveau, il s'agit d'un adressage logique et non pas physique.
 
Pour le cas 1, on est bien d'accord, le SGF va chercher à positionner le fichier toto.TXT a une adresse logique qui lui permettra d'allouer (et donc de réserver) une suite contigu de clusters permettant de recevoir toto.txt. Comme nous sommes sur un seul DD, l'adressage logique sera identique à l'adressage physique.
 
Pour le cas 2, c'est différent.
Logiquement, la partition est adressée comme s'il n'y avait qu'un seul DD, mais physiquement, il y en a 2 DD, donc deux adressages. Sinon le SGF serait incapable de récupérer le fichier s'il ne sait pas adresser physiquement le bon disque via le controleur raid.  
 
C'est pour cette raison que dans le premier cas, la réservation de l'espace disque s'effectue sur la taille du fichier soit 32Ko, alors que dans le cas 2, la réservation de l'espace disque s'effectue sur la taille d'un segment soit par cycle de 4ko.
 
 
D'ailleurs, tu l'as constaté toi même, en raid, l'activité disque est supérieure :
 

La FAT doit être bcp plus grosse en RAID0 alors ?
 
Et comment expliquer qu'on puisse cloner un DD simple sur une array ?

Pour NTFS on parle de MFT et non FAT comme pour FAT32.
 
La MFT en NTFS est beaucoup plus volumineuse que la FAT parce qu'elle basée sur une archi différente et en plus intégre un espace pour les petits fichiers qui ne sont donc pas adressés sur le disque mais conservés en "table d'alloc".
La taille de la MFT est dépendante de la taille de la partition (env. 12% je crois de la taille du disque ou du raid).
 
Par contre, je ne sais pas comment est organisée la MFT sur les DD d'un montage raid 0 au moment de la création de la partition ? Splité sur chacun des DD ? Unique sur l'un des deux ?  
 
Perso, si j'avais eu à l'architerturer, je l'aurai créé en redondant sur les deux DD. Mais j'ai pas la moindre idée de l'impact sur les perfs de cette hypothèse ... Ceci dit, ca a aurait au moins l'avantage se sécuriser la MFT dans le cas où l'une des MFT serait corrompue, les données resteraient quand même récupérables. Vous en pensez quoi ?
 
A noter que la redondance du 1er enreg de la MFT en miroir sur le second n'est pas suffisante.

La MFT c'est d'un point de vue OS, donc c'est réparti sous tout les disques durs.

 
Ok, mais sais tu comment c'est organisé ?  
Par exemple, les 10 enregs de la MFT créé à la création de la partition sont répartis comment sur les DD de la grappe ?

salut à tous, je viens vous couper dans votre débat.
 
Je voudrais passer de 4*250go à 2*500+ l'ajout de 2*74raptor.
Je fais surtout du jeux, de la HD, compréssion décompression etc...
Le gain sera t'il visible ? je devrais mettre mon OS sur le raptor et mes jeux ou ?
J'ai un peu de mal à réaliser enfait ce que les raptor vont améliorer par rapport a ma solution actuel

Si tu sais pas à quoi sert un raptor, ptêtre que t'en as pas besoin

 
lol
 
Si je sais que son temps d'accés est meilleurs, qu'il a une plus large bande passante, mais je veux dire que je sais pas ou il sera le plus utile hormis en OS ( jeux traitement gros fichiers etc... )

Bonjour à tous,
 
une petite question pour les pros :
j'ai une carte mere Asus M2NE chipset nvidia ; un disque sata de 320go divisé en 3 partitions, dont la 1ere contient mon OS ; je viens d'acheter 2 autres disques identiques sata.. je voudrais passer en raid 5, mais ne rien perdre sur mon disque 1 et ne pas avoir à reinstaller mon OS.. c'est  possible ???
merci

Avec certaines cartes peut-être, avec un raid de chipset j'en doute.
 
De toute façon le RAID5 pour un OS bof bof.

 
Tu fais du jeu : stocke tes jeux dessus
Tu fais de la video : stocke tes videos dessus
Tu fais de la retouche photo : stocke photos dessus
Tu fais les 3 : achete 3 raptors

 
... et un casque anti-bruit !    

Salut, j'aurais une petite question :
 
Je suis en train d'acheter une nouvelle tour avec une P5E (X38) et 4 x 7200.11 500Go montés en RAID 1+0
Le choix de ce RAID est d'associer performance avec sécurité des données. Je le privilégie au RAID 5 car en cas de reconstruction de la pile, on perds beaucoup de performances    
L'inconvénient du 1+0 est le prix qui revient à peu près à 440€.
 
1) Que me conseillez vous de faire sachant que j'ai besoin de 1To de données à peu près, que je privilégie la sécurité mais ne crache pas sur une augmentation des performances.
 
2) Utiliser le mode RAID de la carte-mère n'est-il pas trop risqué ?
 
3) Si justement au niveau des drivers ou de la puce si elle merde, je perdrais l'intégralité des données ou elles seraient récupérables sur n'importe qu'elle carte-mère faisant du RAID 1+0 ?
 
4) Ne vaut-il mieux pas utiliser les HDD sans RAID et utiliser un HDD externe pour être plus sûr de la sécurité des données ? (achat d'un 7200.11 1To et un HDD externe de 500Go par exemple)
 
Par avance, merci pour vos conseils

Le RAID 1 ou 5 c'est conçu pour la continuité de service, pas pour sécuriser des données. Pour ça, rien ne vaut un backup.

j'abonde dans le sens de la réponse de asmomo.
2) le risque de disfonction est le même à mon sens, parcontre avec une carte dédié tu pourras probablement, si tu reste sur des produits de qualité, trouver une remplaçante compatible.
3) je sais pas
1) et 4) si tu n'as pas de besoins spécifiques en débits, rien ne t'oblige à céder à la mode du raid qui sévit actuellement chez les particuliers "informati-philes".
tu peux très bien utiliser 2 hdd en backup, dans des boitiers externes ou mieux dans des racks extractibles qui s'insèrent dans des boitiers externes.