Reprise du message précédent :
Le vrai problème est posé par la taille du segment. Plus cette taille est petite, plus le nombre de segments est important, plus le chainage est long, plus il y a de déplacements des têtes (C'est difficile à décrire sans schéma).
Mais en gros la table d'allocation contient le chainage des adresses physiques permettant de connaitre le début et la fin de chacun des segments constituant une unité (dans notre cas, un fichier) et leur chainage pour la reconstitution logique de celui-ci.
 
Donc plus de segments, plus d'adresses à accéder, plus de déplacements des têtes, plus d'usure du mécanisme, d'où plus de nuisances sonores.

CQFD.  
 
J'aurais mieux fait de venir poser des questions ici avant de faire fonctionner "ce raid 0 de malheur".    

J'ai deux remarques :
 
Sur l'apparté sur le Raid 5 : en allant lire l'article sur wikipédia on voit pourquoi, il ne faut pas compter sur le raid 5 pour garantir la récupération des données avec des solutions milieu ou bas de gamme (en tout cas avec  une solution chipset)
 
Sur l'usure : autant que je connaisse le sujet, il y a une gosse confusion des genres : l'écriture sur la FAT et le découpage en cluster est lié à la vision de l'OS des disques durs logiques ( ici on sera parlera de NTFS, FAT32 et consors).
Avec un system raid, l'OS va voir un seul disque dur physique (alors qu'il y en a que deux), et le découpage en segment du raid n'a rien à voir avec le découpage en clusters de la partition.
Donc si on écrit un  fichier de 256 (non fragmenté) il va il y avoir du point de vue de l'OS au moins deux écritures (je crois qu'avec NTFS il y en a plus mais ça ne change rien au problème): une sur les clusters de la FAT et une sur les clusters du fichier.
Avec un système non raid, cela se traduit effectivement par deux écritures sur le disque aux endroits calculés par l'OS. les 256 Mo étant sur des clusters consécutifs du disque.
Avec un système raid et des segments de 64k : chaque écriture va être répartie entre les deux disques, au fur et à mesure de leur arrivée :
la fat réparti sur le deux disques et le fichier sur deux segments de 64K consécutifs sur chaque disque.  
Je ne voit pas pourquoi il y aurait une plus grande usure dans un cas.
(Et le fait que la réalité physique des disques durs fait que la notions de deux clusters physiques consécutifs est quelque chose de complexe, ne change rien car elle impacte pareillement les deux systemes)
Mais il y a peut-être quelque chose qui m'échappe.
 
 
UVB

C'est marrant les coïncidences :
--> http://www.matbe.com/actualites/?start=0#news29201
"[...] Samsung vient de lancer [...] disques durs Spinpoint F1R [...] spécialement conçus pour un usage intensif. Ils visent particulièrement [...] les utilisateurs de Raid 0.[...]"

UVB, c'est juste sauf que les segments ne sont pas consécutifs, enfin, physiquement parlant. Logiquement, ils le sont parce qu'il s'agit d'une chaine d'adressage, mais physiquement les segments sont géographiquement distants.

Il y a-t-il une explication à cet état de fait ? Parce que à priori, ça semble se compliquer la vie de mélanger les segments plutôt que de les ranger dans leur ordre logique.

Oui, c'est (essentiellement) du aux emplacements disque pris et libéré par des fichiers (pour la plupart du temps) temporaires. Ces fichiers sont écrits effacés puis encore écrits etc ... ce qui transforme notre DD en gruyère (d'où l'intérêt de la défragmentation). Ce qui fait que des emplacements plus ou gros se créés.
Ensuite quand tu arrives avec ton segment de quelques k, le système ne va pas allouer ce segment n'importe où mais à un emplacement physique qui lui permet d'optimiser les espaces disques disponibles.
 
De plus, les têtes se déplacent non seulement pour écrire les segments mais aussi pour récupérer des informations qui sont situées ailleurs sur le DD. Les têtes ne restent pas en place entre l'écriture de deux segments. C'est vouloir coller les segments qui compliquerait le boulot.

L'auteur n'est pas repassé depuis 20 posts, je sais pas si c'est la peine de continuer à vous prendre la tête.
 
J'ai pas tout lu donc dsl si qq1 l'a dit avant, mais on ne fait pas un RAID avec un disque qu'on a déjà et un nouveau disque, car il y a peu de chances qu'ils soient identiques, or on fait toujours un RAID avec des disques les plus identiques possibles.

J'ai un raid 0 + 1 et je suis satisfait par cette solution
Effectivement je pense pas que mettre toutes ses données sur un raid0 soit une bonne idée, avec le risque d'oublier de faire les sauvegardes !

Pourquoi arrêter? Cette discussion profite à tout le monde! Et rares sont les discussions aussi techniques sur le raid!
Perso, ça me passionne presque, c'est loin de me "prendre la tête" .

Si vous voulez discuter du RAID pour le sport, il y a un topic dédié.

Je ne suis pas d'accord, il sagit là de la gestion de l'OS, les effets seront strictement les mêmes que l'on soit en RAID ou pas.(fragmentation du disque)
 

Je pense que tu parles de fichiers temporaires créés par l'OS, donc même chose que précédemment
 

Je dirais même que les têtes ne restent pas en place entre l'écriture de deux secteurs et que l'enchaînement des secteurs vu par le bios (LBA) et la disposition physique des secteurs n'a rien à voir. Le contrôleur du HD gère ça, pour que ce soit optimum dans le cas d'une écriture/lecture en continue. En tout état de cause, quand on parle de la position des têtes de lecture on est à un niveau au dessous du BIOS, invisible de celui-ci, et les problèmatiques soulevées seront les mêmes que l'on soit en RAID ou pas.
 
Donc tout ça ne m'explique pas pourquoi, il y aurait une usure prématurée des DD en raid 0 à utilisation équivalente d'un système non RAID.

Pour moi il n'y a pas d'usure prématurée. Par contre une couille (logicielle ou matérielle) cause bcp plus de dégats avec le RAID.

Du genre un ptit truc corrompu à cause d'un plantage ou quoi, peut s'amplifier rapidement, ce qui expliquerait son histoire de PC à l'agonie.

Il m'est arrivé pareil avec mon premier RAID0 il y a bien longtemps (en Athlon pas XP, j'avais la première mobo grand public équipée d'une puce RAID). Dans mon cas c'était le driver RAID qui n'était pas tout à fait au point.

Ca je le comprend mieux, mettre une couche logicielle supplémentaire, apporte son lot bugs. (En l'occurence, je crois la technologie mature pour le RAID 0, mais pas pour le RAID 5)
 
De plus au niveau matériel, mettre 2 DD en raid 0, c'est deux DD qui consomment, chauffent et font du bruit exactement au même moment avec les désagréments éventuels qui vont avec.
On peut y voir l'origine des déboirs de certains.

C'est différent, en raid c'est toi qui décide de la taille du segment. Si tu prends un segment trop petit, tu multiplies les déplacements des têtes. C'est donc différent.
 

Idem

Tu es descendu au niveau le plus bas du découpage du disque, le secteur (soit 512 octets, enfin la dernière fois que je l'ai vu).  
Mais encore heureux que l'écriture des fichiers se fait sur des secteurs consécutifs dans la quasi totalité des cas pour peu que le disque soit défragmenté de temps à autre. D'ailleurs, c'est quand ce n'est plus le cas que l'on considère qu'il y a fragmentation.
 
Dans le cas, d'un DD simple et défragmenté, un fichier de 0,9 Mo par exemple, se placera sur 1800 secteurs consécutifs. Dans le cas d'un raid 0 sur 2 DD, avec segment de 128 ko par exemple, il y aura 8 segments de 128 ko utilisés (à noter qu'il y a une place perdue brut de 124 ko qui sera inexploitable). ces 8 segments seront répartis sur les 2 DD (segments impairs sur l'un et pair sur l'autre) ce qui générera pour chacun d'eux 4 positions secteurs différentes (une position par segment).

Encore une fois je pense que tu confonds le comportement de l'OS avec la système de fichier et le comportement du bios avec le RAID
 
Ainsi les explications que tu donnes sur la perte de place s'appliquent à FAT, NTFS... Je ne vois par pourquoi elles s'appliqueraient au RAID.
J'ai deux disques en RAID 0, l'OS a créé une partition NTFS avec des clusters de 4Ko alors que mes segments sont de 64ko.
Un fichier de 1 octet occupera 4 Ko. Il ne peut pas en occuper 64 car l'OS n'a aucun moyen de connaître la taille des segments, il va donc demander des écritures sur les clusters suivant qui peuvent être dans le même segment.
Ainsi ma partition contient 56009 Fichiers et 4365 Dossiers pour 10 577 523 205 octets mais ils en occupent 10 414 734 692 petit calcul : 2696 octet perdus par fichier, un peu élevé pour une perte située entre 0 et 4Ko par fichier mais très loin de ce qu'avec ton explication je devrais perdre si en moyenne je perdais la moitié d'un segment de 64k (soit 32Ko)

Je ne confonds pas OS Bios et autre notion de raid.    
 
Reprends mon exemple et dis moi ce qui n'est pas exact selon toi.
 
Parce que les 8 segments seront tous alloués à ce fichier et que la place non utilisée sera perdue et inexploitable. Je te trouverai un lien qui explique celà, mais pas aujourd'hui, je suis un peu court en temps.
 
Sinon, là, tu n'abordais que la partie place perdue, mais la question de départ concernait la suractivité des têtes de lecture/écriture en raid.
Est ce que sur le split des segments tu es d'accord ou non ?
Je vais essayer (mais par écrit, je ne garantie rien) de donner un exemple qui provoque le split dans le cas du raid qui n'arrive pas dans le cas d'un disque seul.
Je repars de notre exemple de 8 segments de 128ko pour notre fichier de 0,9Mo.
Dans le cas d'un disque seul, le fichier sera écrit d'un seul tenant pour peu que le disque ne soit pas complétement fractionné, mais dans le cas d'un raid, sur chaque DD, chaque segment sera écrit un par un à un emplacement pouvant acceuillir ce seul fragment sans le fractionner, mais rien ne garantie que le segment suivant pourra être écrit dans la continuité du précédent, il sera donc adressé ailleurs ce qui provoquera un déplacement de tête supplémentaire (je schématise, bien sur). Ce déplacement n'existe pas dans le cas d'un DD unique. Voilà qui explique pourquoi en cas de raid, il y a une suractivité des têtes. Est ce que l'on partage sur ce point ?
 

Comprends pas ce que tu veux dire. Un raid n'est que la simple création d'une partition sur 2 (ou+) disques.
 

 
Tu peux me dire où tu as pris ces deux données ?

UVB : "Encore une fois je pense que tu confonds le comportement de l'OS avec la système de fichier et le comportement du bios avec le RAID"
 
 
Non je ne pense pas qu'il y ait de confusion entre l'OS et la surface du disque de la part de twistou, pour une simple raison : le controleur est bien obligé de demander aux disques de référencer les positions des fichiers. Pour un seul fichier, chaque segment ayant sa propre "individualité" et étant enregistré à la volée : le nombre important de segments implique des accès en écriture plus nombreux pour référencer les différentes positions sur le disque occupées par un seul fichier.  
Ce n'est pas le cas pour un hdd single où un fichier n'aura qu'une ou quelques positions référencées (sauf s'il est fragmenté de manière délirante naturellement!). Je ne suis pas sûr que l'on retrouve ce phénomène sur le raid-0 en lecture dans les mêmes proportions, mais en écriture ça en est même audible chez moi !
 
D'où, avec le succès croissant chez les particuliers des raid, l'idée des constructeurs de proposer de plus en plus des disques pour particuliers "renforcés" en vue d'une utilisation raid (et accessoirement avec un mtbf plus élevé).
 
Aparté :
Le dernier morceau à écrire d'un fichier n'occupera pas la taille d'un strip de 64ko sur le hdd, le strip ne sert que pour le découpage et à la répartition sur l'un et l'autre disque. Heureusement!
Cela étant lorsque l'on enregistre un grand nombre de petit fichiers on constate une perte de place, mais celle-ci est fonction de la taille de cluster que l'on a défini au moment de la création de la partition (celle-ci pouvant varier dans mon cas de 512o à 64ko). A titre d'illustration, j'utilise mon raid-0 pour faire du montage video, donc de gros fichiers. J'ai attribué à ma partition raid-0 une taille de cluster de 16ko (partigion magic par exemple permet ce genre de chose). Si je m'amuse à y stocker un dossier de petits fichiers (+-1500 fichiers et +-20mo), j'arrive à des pertes de l'ordre de 14% entre la tailles des fichiers et la place occupée sur le raid. Mais tout ça est hors-sujet et pas très intéressant.

 
Je crois que c'est là que nous ne voyons pas la même chose : la fragmentation vient de l'utilisation des clusters. Si ce n'est pas fragmenté au niveau du NTFS ce ne l'est pas au niveau des segments et réciproquement
Les segments organisent les secteurs -donc les clusters- en groupe, comme on utilise des puissances de deux, il tiens un nombre entier de clusters dans un segment (disont huit) . Si l'os voit un groupe de 57 clusters libres consécutifs qu'il veut remplir il envoit les données à la suite.
Avec un DD simple cela se traduit pour l'écriture à la suite des 57 clusters : pas déplacement intenpestif des têtes de lectures.
Avec 2 DD en raid 0, l'emplacement physique de ces 57 clusters est plus complexe disont qu'ils commencent au cluster 400 de chaque disque (donc au début du 50e segement de chaque disque):
 1- 8 : 401-408 du DD 1
 9-16: 401-408 du DD 2
17-24: 409-416 du DD 1
25-32: 409-416 du DD 2
33-48: 417-424 du DD1
49-56: 417-424 du DD2
57 : 425 du DD1
On se retrouve donc avec une écriture sur le DD1 sur les clusters 401 à 425 et une sur le DD2 sur les clusters 401 à 424 ( j'ai commencé l'écriture sur un segment entier pour simplifier, mais ça ne changerai rien au principe)
 
Donc sur le principe le RAID 0 n'implique pas une usure prématurée des disques.  
Je réfute aussi l'argument qu'ils sortent de DD spécial raid 0 pour contrer cette usure, je met ça sur le compte des même personnes qui vous expliquent qu'un APN 12 millions de pixel c'est mieux qu'un 6 millions: le service marketing
 
Par contre, bien que je persiste dans ma position, je viens d'abandonner ma configuration RAID 0.
Pourquoi ? Parce que je considère après utilisation, que la gestion par CM du Raid n'est pas mûre.
Problêmes rencontré :
- Impossibilité d'accéder au smart (vous avez un système moins fiable et vous perdez tout moyen de surveiller sa santé)
- Freeze temporaire ou définitif avec erreur raportée par l'utilitaire de NVIDIA (dans une bulle d'aide qui apparait à l'écran) de surveillance du RAID : uniquement lors des chkdsk. A la fin du freeze : rapport de l'utilitaire : tout va très bien !!! pas de log d'erreurs. Tests avec seatools (dont test de surface complet) : les DD vont bien, chkdsk complet au lancement de la machine, tout va très bien.
 
Moralité : vous pouvez faire du raid mais sans smart et sans chkdsk... à vos risque et périls !!
 
Je ne contrerai donc aucun argument qui dirait que le raid sur CM étant mal foutu cela provoque une usure prématurée...
 
Merci à tous pour cette discussion interressante..
 
UVB

je vois pas de raison a avoir de restriction au niveau de chkdsk.

C'est quoi comme contrôleur nvidia ?

Chipset nVIDIA® nForce 570-SLI  

 
C'est précisément là, où je ne suis plus d'accord. Rien ne permet de garantir la séquentialité d'adressage des secteurs utilisés entre deux segments.
 
Moi aussi je trouve cette discussion intéressante.  

 
Par contre là, je ne comprends pas ce que tu veux dire.  
Un cluster est un nombre entier de secteurs minimum utilisé à l'écriture d'un fichier.
Taille minimum occupée par un fichier >= 1 cluster (même si le fichier fait 1ko.)
 
Un secteur est la plus petite subdivision d'un plateau.
 
La fragmentation est le résultat d'une insuffisance de place pour loger un fichier dans sa totalité. Celà se traduit par un chainage d'adresses indiquant, entre autre, le positionnement du fragment précédent/suivant.
 
Et celà n'a aucun lien avec les segments qui sont une subdivision logique utilisée pour une écriture en raid.  

Les sujets suivont ont étés fusionnés à ce sujet par Asmomo

• Raid 0

Hop petit fusionnage, je pense que la discussion est intéressante pour tous les participants au topic RAID, et j'avais envie de tester mes pouvoirs

 
Comment sont organisés les segments sur le disque ?
"Deux" solutions : (en fait qu'une)
Si c'était dynamique, il faudrait une table quelque part qui indique ou est le segment recherché. Et pour pas la perdre entre deux allumages il faudrait quelle soit sur le DD, ce qui impliquerai des lectures/écritures en permanence sur cette table. effectivement alors il y aurait une chute de performance et une usure énorme. De plus en cas de coupure d'alimentation secteur, la table risquerais d'être corrompue et alors perte du contenu du disque.
Classer les objets de façon dynamique n'a d'interet que si on range des objets en nombre variable et de taille variable (ce que fait le système de fichier)
Donc solution compliquée, dangereuse et sans intérêt. Je prend pas de risque à parrié que c'est pas celle utilisée
 
Donc c'est statique :
le segment N°1 est toujours à la même place sur le disque quelque soit le nombre de lecture/écriture, le bios utilise une formule pour déterminer les différents secteurs qui composent ce segment.
La solution la plus simple est de les ranger dans l'ordre, les premiers en premiers et les derniers en derniers, en plus il suffit d'une formule toute simple pour calculer le DD ou le N° du segment auquel appartient le secteur.
Exemple pour des segments de 64 secteurs , si les N° de segment et secteurs commencent à 0 avec 2 DD :
N° Disque = (N° \ 64) % 2 ( \ division entière, % reste de la division entière aussi appelé modulo, ça donne 0 ou 1 suivant le disque)
N° Segment = N°  \ 128
Dans ce cas les segments consécutifs sont placés consécutivement sur le DD
Effectivement on pourrait prendre d'autres formules, voire une table de correspondance fixe dans l'eprom, histoire de se compliqué la vie pour faire moins performant. Mais comme je crois que les informaticiens sont faignants de nature je pense qu'ils ont utilisé la solution qui était à la fois simple et efficace...
 
De plus ce qui use les DD lors d'accès à des fichiers fragmentés c'est de déplacer la tête de lecture donc pour que l'usure soit notable il faudrait qu'en plus les secteurs soient placés de façon relativement éloignée (parcourir au moins 5% du disque soir quelques Go, ou 20 000 secteurs d'écarts) pour que l'usure soit perceptible, si pour une raison xy les secteurs étaient entrelacés (les secteurs logiquement consécutifs en fait écartés systématiquement d'un secteur) ça ne changerait rien à l'usure.
 
A noter que pour avoir un avis d'un technicien en la matière, il faudrait qu'il travaille chez un fabriquant de chipset, de carte mère ou de DD.
 
UVB

Putain ce thread est long est lourd à lire.
 
Mais a mon humble avis le RAID n'use pas plus que ça les HDD. La vrai impact c'est que le moteur tourne plus car on n'as rarement voir jamais de veille sur les HDD quand on est en RAID.
 

S'pas bien ca  
Je retrouvait plus le petit topic  
 
En tout cas, fonction fusion parfaite  

 
Tout à fait d'accord avec tes définitions.
Plus précisément pour le cluster c'est un nombre entier de secteurs utiliser pour chaque écriture dans un fichier. Je veux dire qu'un fichier de 5 secteurs avec des clusters de 4 secteur, occupera 8 secteurs.  
 
Après, c'est juste que le chainage se fait par groupe de cluster
 
Méthode DOS/FAT (simple et stupide)
J'ai un fichier de 10 000 octets et des clusters de 1024 octets.
Je cherche la première place libre sur le disque : oh! elle fait 2 clusters, j'y met les 2048* premier octets
Je recherche la deuxième place libre : 3 clusters , hop 3072* octets
Je recherche la 3e place : 5Mo, j'y place les 4880* octets restants dans les 5 premiers clusters libres, mon fichier de 10 000 octets prend 10 240 octets sur le disque et est en 3 morceaux
 
CQFD mon disque est fragmenté !!! l'explication reste la même qu'on soit en RAID ou pas
 
* Je ne sais plus si les adresses du chaînage étaient stockés dans la FAT ou dans le cluster du fichier, dans ce dernier cas (mais je crois pas), ça laisse un peu moins de place pour les données, mais ça ne change pas le principe.
 
De même que pour les segments, la numérotation des clusters se fait de façon automatique à partir de celle des secteurs, dans l'exemple ci-dessus il suffit de diviser par deux le N° de segment pour obtenir le N° de cluster.
 

pourquoi dis-tu cela ?

J'avoue j'ai survolé, mais tout vos cratage de cerveau avec cluster/segment et les débats sur les SGF c'est useless pour le RAID.
 
Le RAID est un niveau d'abstraction très bas. Alors pour le SGF et l'OS ca ne change rien.
En RAID la fragmentation moyenne est identique que sans, l'usure du disque aussi.
 
Pour le SGF le "secteur" 0 est la somme des n-secteur 0 sur les n-HDD composant l'array RAID. C'est simpliste certes, mais ça suffit a tout expliquer.
 
Sachant qu'en RAID0, tout fichier < au Strip Width n'est que sur un HDD. Y'a donc que ces cas là qui sont un peu chiant. Mais ils demeurent rares, et les controlleur (enfin les pilotes) ont du s'adapter au fait que le NTFS soit quasi obligatoirement faire de cluster de 4Ko.

 
C'est ce que j'essaye d'expliquer !!

 
ça transfère pas le drapeau ?

C'est impossible, une fois le segment copier de la mémoire sur le DD, l'emplacement ne peut pas être réutilisé sur le DD. Par contre qu'une fois écrit l'emplacement mémoire est libéré pour accueillir un autre segment est un autre sujet.
 
J'avoue que j'ai du coup beaucoup de mal à te suivre. J'ai un peu l'impression que tu développes suivant une approche de programmation avec des adresses mémoires réutilisables une fois libérées.
 
Ceci dit, je vais te répondre en répondant à MEI sur le même sujet, histoire de ne pas répondre deux fois la même chose ...

Apparement pas

 
C'est sur ce point précis que je ne suis pas d'accord.
Ceci est vrai dans le cas ou un DD est défragmenté, mais plus la fragmentation est avancée moins c'est vrai.
 
Pourquoi ? Parce que simplement à la segmentation, le strip est écrit à la volée à une adresse physique qui ne provoquera pas de fragmentation du strip.  Le segment suivant (pour le même DD donc pair ou impair au choix pour un raid 0 à 2 DD) sera écrit à l'adresse physique consécutive aux clusters qui ont acceuilli le segment (pair ou impair si 2DD) précédent sauf ... en cas de provocation d'une fragmentation. Auquel cas, un chainage d'adresse est constué au niveau de la FAT pour réserver l'adresse physique du premier secteur affecté au segment à écrire.
 
je l'avoue ce cas est loin d'être le plus courant, mais il arrive en raid alors qu'il ne peut se produire dans le cas d'un seul disque que si aucun espace disque ne peut acceuillir le fichier en un seul tenant.

 
 
Ben non, j'ai mis un bout de temps à retrouver le fil ...  

slt à tous
que penser vous de sa,
j'ai une Asus P5B deluxe avec actuellement un raid 0 avec deux raptor 10000 36go et 2 x 1 go  de mémoire G skill
je souhaite acheter deux DD Seagate Barracuda 7200.11 SATA NCQ 3Gb/s - 500 Go 7200 RPM 32 Mo Serial ATA II
comment est ce que vous monteriez tous sa vous sachand que je v rester en raid
merci d'avance pour les différents avis

 
C'est la conséquence de ce que j'explique plus haut.

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...