Reprise du message précédent :

- Le NTFS et tout les SGF journalisé son quasi-insensible a la corruption du à la panne de courant pendant l'écriture. En effet, en principe le CHKDSK remettra le fichier dans son état précédent assez facilement. Bien sur ça peut arrivé, mais on sais contrer se problemes.
 
- Pour les partitions, le NTFS et tout les SGF journalisé on en principe une table d'allocation répartie sur le disque et en plusieurs exemplaire, ce qui fait que normallement pour detruire une partition, contrairement au SGF type FAT12/16/32, il faut vraiment le VOULOIR. (mais un virus y arrive tres bien rassurez vous. )
 
- Le RAID n'a jamais été pour la sécurité des données, mais pour la performance et/ou la continuité de service.
 
 

Pour l'OS, en general, t'as un RAID0 avec un spare ou deux spare. Il te faut pas plus de 30 minutes pour recreer une array et restore l'OS. Alors que le données qui font plus Go, meme avec de la super sauvegarde industrielles, si tu perds ton array car 2 HDD de ton RAID5 tombe d'un coup (ou 3 de ton RAID6, etc.), il te faut ptet pareillemnt que changer un disque, mais ca mette plusieurs heures a etre restauré.
 
Ceci dit, un OS en RAID0 n'est pas forcement utile non plus...

Ouai enfin les données en gros y'a deja ça comme cache :
 
cache de l'OS (en principe qu'en lecture) -> cache du SGF ->  cache controlleur RAID (parfois avec batterie) ou carte pilote -> cache HDD (normallement l'HDD a le temps d'ecrire ce qu'il reste meme avec la panne de courant) -> HDD
 
Apres en gros quand on demande un I/O au SGF, il bufferise en RAM pour limité les I/O physique. Une fois qu'il va envoyé ça à l'HDD physiquement il ecrit certes, mais fait un journal au passage (un peu comme un SGBD). Ce qui veut dire que si tu plante entre le moment ou le SGF va ecrire, et le moment ou l'HDD à fini, de toutes facons c'est perdu, meme si la partition reste dans un etat coherent. Le buffer du SGF est différent de la journalisation. (on peut meme je crois supprimer le cache disque en ecriture sous Windows).
 
Le probleme c'est qu'avec les differents niveau de cache il peut se peut que :
- l'application soit floué par le SGF car il aura encore les données en buffer.
- le SGF soit floué par le controlleur RAID car il aura encore les données en cache.
 

je vais tester l'arrêt du pc pendant l'écriture, on va voir.
 
sinon, ce qui me choque vraiment c'est cette phrase "N'importe quoi   Et je ne vais pas donner un cours sur le mirroring. Tu crois que mes clients mettraient plusieurs millions d'euros pour faire de la maintenance de DD ?"
 
enfin, j'imagine qu'il y a un peu d'exagération et qu'en plus il veut parler de sommes totales .. mais avoir des clients qui payent pour du backup et leur mettre les fichiers sur un seul contrôleur, dans une même tower, sur une même alim (découpage, onduleur, .. tout ce que tu veux), dans une même pièce ... même mes divx sont plus sécurisés que ça ^ ^

Quel argument ? C'est pas un argument. C'est un constat. Fragilité d'une partition ? Mais où as tu vu qu'une partition était fragile, faut pas pousser, si tu joues pas avec, elle n'a rien de fragile. En quoi, c'est fragile une partition ? Ce n'est qu'une collecte d'adresses ...
 
Ta dernière question, je ne m'ai pas comprise ...
 

Le buffer ne contient certainement pas l'intégralité du ou des fichiers et il ne se vide pas dans le néant. Tu parles de chose que tu ne connais pas.    Ca ne marche pas comme celà.

Tu peux dire que c'est la même chose, moi je te dis que c'est pour la continuité de service, pas pour de la maintenance. Maintenant, si tu intégres le recovery à la notion de maintenance ...  
 

 
Non, aucun rapport entre les données et l'os. L'os n'est pas mirroré, tout comme les applications, il est sur un serveur de secours qui ne démarre qu'en cas de chute du serveur principale. Tu vois mieux l'intérêt maintenant. Les solutions de recouvrements pour les données et pour l'os(et les applications) sont différentes : disques mirrorés pour les données, serveurs redonnants pour l'os et les appli.

 
Ok pour tout sauf sur le dernier point, le mirroring est le premier niveau de sécurité. En effet, en cas de défaillance d'un des disques mirrorés , on restaure à partir du second. Bien sur, il y a plusieurs autres niveaux de sécurité des données, serveurs de données sur batiments distants, sauvegarde sur supports mobile, etc...

 
1. c'est fragile, c'est comme une archive, le moindre grain de sel et tu perds l'accès à tout ce qu'il y a derrière. je préfère avoir mes fichiers stockés seuls plutôt que dans une archive comme je préfère avoir mes fichiers dupliqués sur deux partitions plutôt que sur une seule mirrorée. c'est de la logique implacable.
 
je connais pas la raison qui fait que les forumeurs perdent en masse (oui, en masse. proportionnellement à toutes les autres causes, mêmes les causes de casse hardware, c'est loin devant) l'intégrité de leur partition - j'ai déjà essayé de comprendre mais je n'ai pas trouvé de point commun - mais c'est un fait. Pex, dans certains cas sous xp la partition est vue au format raw à cause d'un problème de droits ntfs. c'est pas qqque chose que qqun décide de foirer, c'est comme un lecteur optique ou hd qui passe en pio alors que t'as rien fait pour, c'est xp qui est prévu comme ça (genre, le mode pio pour ne pas répeter des erreurs survenue en dma)
 
2. tu parles de fonctionnement de buffer, moi je parle d'arrêt de l'écriture physique.
 

 
Exact, mais dans le cas présent, je parlais buffering applicatif qui garantit l'intégrité des données dans un cycle. Les disques étant mirrorés, le commit n'étant pas réalisé dans le même elapse, mais sérialisés, quels sont les cas de figures :
1. Le clash arrive lors du commit sur le premier DD. Le premier DD est corrompu, le recovering se fait à partir du second, on retrouve l'intégrité des données d'avant le commit.
2. Le premier DD est mis à jour, le clash a lieu entre les deux MAJ. Le second DD est corrompu, le recovery se fait à partir du premier vers le second.
Dans les deux cas, on retrouve l'intégrité des données. Seul dans le premier cas, la mise à jour n'a pas eu lieu, il faut une intervention manuelle pour réaliser cette mise à jour. Mais le principal, qui reste l'intégrité des données, est conservée.

 
   Eh bien, si mes clients payaient autant pour si peu, je serais un voyou ...  
 
Je te parle de lames, de lames redondantes, de procs que l'on affecte à chaud, dans des batiments sécurisés et doublés, de rack de DD mirrorés, ... et pas pour du backup mais pour de la continuité de service. Mais que l'on parle de raid ou de disk mirroring, que l'on parle de la petite application sur un mono serveur ou de ce que je liste plus haut, le principe est le même, seul les enjeux et les SLA différent ...

Mais voyons qu'est ce qui est fragile ? Il n'y a rien de fragile dans le mirroring.  C'est tout le contraire.
 
En plus tu parles, je te cite, "d'avoir tes données sur deux partitions plutôt que sur une mirrorée". Ca veut dire quoi ? parce que si tes deux partitions sont sur le même DD, et bien c'est comme si tu n'en avais qu'une si ton DD se crache, 2 partitions ou 1 t'as tout paumé.
Il faut que les 2 partitions soient sur 2 DD différents donc 2DD mirrorés (on mirrore les disques, pas les partitions). Quant à la logique implacable ... Dis pas celà à un architecte  
 

Ca ne change rien, le buffering ne fait que garantir l'intégrité physique des données, et il précède l'écriture physique. D'ailleurs j'en parle un peu plus haut en donnant les deux cas de figure qui peuvent arriver (enfin, en ayant simplifié au max le fonctionnement).

 
je vais arrêté là
 
parce que tu reviens sur tes dires :
 

 
Tu peux arrêter là si tu veux, je ne reviens en rien sur ce que j'ai dit, je persiste et signe, mes clients ne claquent pas des millions pour de la maintenance, mais pour avoir la continuité de service, si tu ne fais pas la différence qui puis-je ?
Je sais ce que je leurs vends et pourquoi je le leur vends, tu peyx me croire.  
 
Enfin, j'espère que nos échanges t'auront appris un tas de trucs, mais c'est dommage que tu le prennes ainsi ...

 
euh, "garder en ligne" c'est synonyme de "continuité de service" non ? .. continuité pendant laquelle est faite la maintenance des hd qui ont ou vont lâcher pex ...
 
 

 
euh, au départ on donnait des conseils sur un choix de raid 1 onboard, je pense pas que cette gamme de chipset fasse ce genre d'opération. maintenant si je me trompe. ils ont fait de sacrés progrès sur des cablages à 2 euros.
 
de toute façon, je pense que tu n'a pas compris le genre de corruption/effacement dont je parlais, faut pas se focaliser sur l'exemple 'simpliste' de l'arrêt de la machine que j'ai donné. il y en a des tonnes qui sont indétectables via contrôleur.
 
je suis pas informaticien et pourtant des corruptions j'en ai vu. je donne juste un exemple d'un chip raid onboard sur une nf2 qui corrompt - à l'aller ou au retour - (uniquement) certaines archives zip/rar si elles transitent par une carte ethernet giga (n'importe quelle marque, modèle). dans ce cas là si on se contente d'un raid mirroré et qu'on ne teste pas les archives on aura juste une montagne de fichiers bon à mettre à la poubelle au final.

 
 
Ahh, ben ouais si tu veux, c'est un peu tiré par les cheveux. La continuité de service conserne les applications pas l'os, mais bon, passons ...    
Et pour la maintenance, j'ai vu plus haut que pour toi celà intégrait le recovery. Bon, ce ne sont pas les bons termes que tu utilises, mais l'idée est bien là.

 
Ben c'est vrai que si on fait n'importe quoi, on a deux poubelles. Mais on ne fait pas du mirroring comme on fait du vélo.
 
Mais que tu ais un simple DD ou deux DD mirrorés, si tu ne controles pas la réception de ton fichier rar. Ben t'auras de toute façon une poubelle, raid ou pas, si le transfert s'est mal passé.
 
Maintenant, si tu fais du raid, parce que tu as une bonne raison de le faire, tu positionnes un controle automatique des transferts (lecture/ecriture/relecture) qui t'assure que le transfert s'est bien passé.
 
Bon, sur ce dodo, une grosse journée m'attend demain. Bonne soirée c_planet.

Je suis tout à fait d'accord avec c_planet sur le fait que les partitions peuvent être assez facilement niquées, et que tout peut arriver malgrès les moyens mis en oeuvre pour prévenir et réparer les erreurs. En théorie, la partition est parfaite, y'a des controles d'erreurs partout, des tas de mécanismes de protection qui font que "rien ne peut arriver" En pratique: mon cul, la loi de murphy est là, quelque soit les millions qu'on y mets, le 100% fiable n'existe pas.

Hum cad que quand t'as deux site, avec chacune deux baie, avec chacune 2 lien Fibre/2 lien d'alim, avec chacune un RAID1 au final t'as :
 
2x moins de chance de perdre tes données a cause d'un incendie.
4x moins de chance a cause d'une panne total d'une baie.
8x moins de chance a cause d'une panne d'alim ou d'une perdre de liaison physique.
16x moins de chance a cause d'une panne d'HDD.

 
Apres pour moi la continuité de services implique la capacité a maintenir le materiel rapidement. Car si ton HDD crame, tant que tu ne le remplace pas tu perd ta qualité de service.
 
Rapellons aussi que dans l'informatique de ce calibre le stockage est mutualisé et que si le serveur applicatif tombe c'est different, là c'est des serveur en load balancing qui accede chacun a la meme baie qui est en realité "virtuelle" puisque egalement distribué en cas de panne.
 
Sinon twistou t'es architecte donc ?

 
Malheureusement je n'ai pas le budget pour des raptors    
 
Comme DD, j'ai ca :  
http://www.ldlc.com/fiche/PB00028993.html
 
Si il fallait 2 DD identiques, je pensais m'orienter là dessus :  
http://www.ldlc.com/fiche/PB00041254.html
ou meme http://www.ldlc.com/fiche/PB00016093.html ?
 
Ca vaut pas le coup ?

 
Ah voilà un language que je comprends.
Non, je ne suis pas archi, mais DP. Ceci dit, je peux monter, une archi n-tiers dans une proposition en la faisant valider par un archi. Disons que je touche un peu au sujet par la force des choses.  
Par contre, il semble que tu connaisses bien le sujet, parler de baies de disques, d'environnements mutualisés et de load balancing en est un signe probant.  

 
Je dis pas le contraire mais un raptor ça coûte super cher non? Et surtout ça fait un max de bruit il paraît?
D'ailleurs à ce sujet, il fait du bruit que lorsqu'il s'existe ou tout le temps? Car le pc est dans ma chambre et je vais me faire une config silencieuse (alim fanless + WC), donc si je pouvais avoir des HDD qui ne s'entendent pas au repos ça serait top...
 
Si vous pouvez me conseillez à ce niveau    
 

 
Bà ouais mais ma config sera principalement orienté jeux, et dans ce cas là les Quad ne servent à rien, voir son même moins performant...va savoir pourquoi!
Oui mais pourquoi je prendrai 2 vieux raid0
 
J'ai déjà fais du raid0 y a 2 ans avec des bons hitachi et je voyais vraiment une différence de performance quand même:
-boot plus rapide de windows et de toutes applications (jeux, programmes)
-les copies de fichiers...rien à voir!
-toutes manipulations qui provoquaient des gros accès disque (décompression etc...) sont carrément moins relou, le pc répond encore correctement et tu peux te permettre de cliquer sur un programme et de pas attendre pour qu'il s'ouvre! Bref le RAID0 c'est pas non plus inutile niveau perf....bon j'ai arrêter car le controlleur m'a laché!

euhhh j'étais justement en train de me le demander. J'ai actuellement un raid0 de raptor 74Go pour l'OS + jeux. Je me tate à le reserver qu'au jeux et prendre un autre raptor (ou un SSD   ) uniquement pour l'OS...

 
3 raptors ? Le bruit ne semble pas te gêner ...
 
L'idée, c'est quoi ? lancer les jeux plus vite ? Perso, je n'en vois pas l'intérêt.

Bah je t'avouerais que nan le bruit ne me gene pas du tout, avec le P190 j'entend même plus les raptors...
 
En fait je lis de plus en plus (forums, test ect) qu'un raid0 pour l'OS n'apporte rien en terme de perfs, ce qui est primordial c'est le temps d'accés... par contre pour les jeux, ya pas photo, le raid0 c'est magique

 
Ah, il vaut mieux mettre les jeux sur les DD en Raid0 plutot que l'OS ??? j'aurais fais l'inverse moi  

 
Ni l'un ni l'autre à vrai dire, le raid 0, c'est pas trop fait pour celà ...

C'est fait pour quoi alors ?
 
Globalement c'est fait pour améliorer les perfs du DD ... alors c'est vrai, c'est plus adapté pour les grosses copies, m'enfin quand je vois les quantités extraites dans les répertoires temporaires de Windows, jme dis que ca pourrait quand meme pas mal accélerer au quotidien ...

Le RAID0 est fait surtout pour ça   Le mieux est de mettre OS + JEUX en RAID0 avec une partition c:\ la plus petite possible et le d: pour les jeux

Coincidence aujourd'hui j'ai mis un raptor 150Go dans un pc au boulot.
Effectivement le disque est plus bruyant qu'un disque classique, surtout à cause des vibrations amplifiées par le boitier (il faut absolument mettre le disque sur des rondelles anti-vibration)

 
Bah pour moi acheter des 80Go en 2007, non ça vaut pas le coup. Tu vas te retrouver avec 160Go pour le prix d'un 500Go. Certes le débit sera un peu meilleur, mais bon, rien de transcendant. Les DD modernes sont déjà très rapides (en débit), sauf appli particulière ce n'est plus ce qui limite, le pb c'est le temps d'accès.

des disques de 40Go acheté fin 2007
lol quoi
quand tu vois que les derniers jeux bouffe des fois pret de 8Go sur le disque dur (il est pas question de 16Go meme pour un jeu comme crysis)

 
c'est assez bizarre le bug, surtout quand on lit les avis sur le forum de hdtach
 
l'incohérence entre les résultats et le graph !

 
C'est pas une histoire de buffer en RAM ?

 
Les quad servent dans supreme commander, crysis, et ça va pas aller en diminuant.
 
Pour qu'un RAID0 booste les copies de fichiers, il faut... 2 RAID0.
 
Le reste de ce que tu décris est surtout pénalisé par les temps d'accès.
 

 
Au départ c_planet ( ) disait ce qu'on dit couramment ici (ow31 venait d'ailleurs de le répéter), à savoir que le RAID1/5 n'est pas une solution de backup, mais de continuité de service. Tu t'es enflammé en disant que c'était n'importe quoi, puis de fil en aiguille tu dis finalement exactement la même chose que nous. c_planet n'a donc plus besoin d'argumenter.

C'est pas un bug. C'est juste que l'activation de l'antememoire fait qu'on a un cache en RAM. C'est +/- la vitesse du bus entre le MCH et l'ICH.

c'est bien ce qu'il me semblait, mais ça ne reflete pas la réalité si je comprends bien

bah eu si, en realité le burst va bien a cette vitesse là si c'est en cache RAM.

 
Ouais enfin tu prends le QX9650 qui coûte 1000€ et qui te fait gagner 10/15% de perf pour supreme commander (un des jeux qui exploite le mieux le multiprocco) par rapport à un E6850 qui coûte moins de 250€... excuse moi mais bon je m'en fou des 10% hein
 
Si tu trouves que le raid0 vaut rien en terme de perf, je crois que tu aurais pu oublier alors de mentionner les quad pour supreme commander    
 
PS: c'est quoi 2RAID0? 4 HDD en raid0? En quoi c'est performant?

le q6600 G0 il coute que 240-250€ hein....  
 
faudrait pas non plus diabolisé le prix des quad
 
et si t attend debut 2008 t aura un quad intel "penryn" pour le meme prix
 
après j ai beau être POUR la multiplication des core  
car en imagerie 3d pour le calcul des scene ou en compression video ça aide
 
sup commander tournait tres bien chez moi avec E6600 non overclocké la 8800gtx fait bien le boulot pour ce jeu
et crysis effecivement pour le moment utilise QUE 2 core d un quad
voir dans de prochain patch pour ce jeu (et futur nvidia "D9E" aidant)  
les autres cores seront un peu plus sollicité en mode "very high" ?
(ou si y a déja qqs opti dans la version final qu on va enfin avoir dans les main cette semaine )
 
enfin à mon avis c est plus beaucoup de memoire vive que de raid 0 qui aide un tel jeu

 
 
un raid 0 de deux disques et un deuxième raid 0 à coté.
 
Quand tu copie un fichier depuis un raid 0, tu le  colle où ?
=> Vers ce même raid 0 ou vers un disque seul, dans ce cas le débit est limité et le raid 0 ne te procure aucun gain.
Le seul moyen de gagner en vitesse de copie de fichier, c'est de copier depuis un raid 0 vers un autre raid 0.