Bongour
 
Voila, j'ai un serveur de fichiers sous linux debian, 2*500go et 2*750, tous en sata.
Pour l'instant, ils sont tous indépendant, chacun a son point de montage.
 
J'ai reçu 2 disques de 1To, n'ayant que 4 ports sata sur ma carte mère, je vais donc garder les 4 plus gros ( 2x750 et 2x1000 ).
 
Dans un monde parfait, mon objectif serait de monter un raid 0 avec toute la famille, les données n'étant pas très/trop sensibles. Mais faire un array de 3.5To en raid 0, je sais pas si je vais prendre le risque
 
Le raid 5? Pourquoi pas, mais étant donné que je n'ai pas 3 ou 4 disques identiques, serait il possible de faire un array de 4*750 et un raid 0 de 2*250 ( espace restant des 2*1To ) ?
 
Sinon, n'y aurait il pas une alternative me permettant de monter tous les disques sur un seul point de montage, on copie la data sur le premier et une fois blindé, le systeme copie sur le 2nd disques etc...? Si un disque crash, je ne perds pas tout.
 
Thx

oui :
1er disque, 1T (sda) : 2 partitions sda1 (750G) et sda2 (250G)
2ème disque, 1T (sdb) : 2 partitions sdb1 (750G) et sdb2 (250G)
3ème disque, 750G : 1 partition sdc1 (750G)
4ème disque, 750G : 1 partition sdd1 (750G)
 
une pile raid, niveau 5 : md5 composée de sda1, sdb1, sdc1 et sdd1
une 2ème pile raid, niveau 1 : md1 composée de sda2 et sdb2
 
bien sur tu peux intervertir l'ordre des partitions sur les deux disques de 1T, ne pas monté les disques dans cet ordre, ou nommer tes devices raid autrement (md0 et md1 ...)
 

 
si, ça s'appelle du JBOD : Just a Bunch Of Disks

Merci pour ces précisions.
Spossible de rajouter un disque à une grappe de raid0 sans perdre toutes ses données? Je sais que ca fonctionne en raid 5...

m'étonnerait ...
 
rajouter un disque à un raid 5, "simplement" c'est le rajouter en spare (a priori il ne sert à rien, n'agrandit pas la taille de la pile raid, il prend juste la place du 1er disque qui vient à défaillir). Après il est depuis peu (en raid soft linux je parle) possible d'étendre sa pile raid 5 (opération grow) mais alors c'est relativement complexe, long (selon la taille de la pile, puisqu'il faut tout reconstruire) et c'est surtout gérer par le driver raid5 ... or je suis pas sur du tout que le driver raid0 propose la même opération

Euh, de memoire, si on perds un dur en jbod, c'est plutot dur de recuperer les datas des autres durs ... a confirmer...
 
Raid Software ou Hardware ? Parce que les perfs sont bien differentes
 
Renseigne toi bien sur le Raid5.
Je ne connais pas le comportement du controlleur sata et des disques lors d'une panne en raid5 sata, mais en ide su controlleur mobo/bas de gamme (comprendre pas du 3ware ou pas du matos pro, celui ci coutant au passage dans les 200 a 300euros le controlleur 2 a 4 ports max), j'ai l'amer souvenir d'un array tout ce qu'il y a de plua inutilisable, et impossibilite de recup les donnees car le controlleur ide etait bloquant, donc des data pourries envoyees au hasard des secteurs au hasard des differents durs de l'array (4x250Go a l'epoque, blindes of course, je me souviens bien de cette amertume quand j'ai decouvert la perte de la totalite des donnees ^^ )
 
Autre probleme a signaler pour le raid : si ton controlleur meurt, et que le raid est materiel, il faut le meme controlleur pour recup tes data....

J'ai fais des tests en raid 0, hdparm me donne un vitesse en lecture identique à un disque seul, probablement limité à cause du controleur sata. Par contre en write ca bourrine pas mal. C'est pratique qd on décompresse des grosses archives mais vu mon utilisation, l'intéret est en fait assez limité et le risque de tout perdre me fait un peu peur.
Le raid5 pourrait être intéressant, mais si un dur lache il faut le remplacer pour réparer les données, ca reste couteux en définitive...
Je crois que je vais partir sur un jbod classique D'aprés ce que j'ai lu on ne perd que les données du disque manquant.  
 

 
Non, comme le dit ensuite KIKAduKANA avec du JBOD, tu ne perds que les données du disque deffectueux, c'est avec un raid0 que tu perds tout ...
 
 
 

 
Là par contre pour le coup, 200% d'ac avec toi, c'est pour ça que je ne fais que du raid soft ...
 

 
Ca c'est normal, le raid0 ne privilégie que l'écriture, pour privilégier la lecture il faut un raid1 (mais on perd en écriture du coup)

 
Et tu m'explique ce que fais le filesystem qui est sur le jbod quand on disk tombe ?

Issu de Wikipedia ( http://en.wikipedia.org/wiki/Stand [...] or_SPAN.29 )
bon, bah en fait ca parle pas trop de linux, en esperant pour toi que tu ne sois jamais face a ce genre de situation...

Y'a plus qu'a tester

 
Le JBOD c'est ajouter les disques les uns derrières les autres ...
80Go + 120Go + 250Go = un espace utilisable de 450Go
 
Tu crées des fichiers sur ta pile, ils sont stockés sur ton disque de 80Go
Une fois ton disque de 80Go plein, ça passe sur le 120G
Une fois le disque de 120G plein, ça passe sur le 250Go
 
Je pense donc, à tort peut être, que si un disque meurt, ok ton FS est un peu branlant, mais doit y avoir moyen de récupérer les données sans trop en chier, en morcelant le FS ...

 
c'est quoi la difference avec un LVM et des pv ?

Si un disque lache , l'array continue en mode dégradé. Vaut mieux éteindre proprement et remplacer le disque mais bon, il tourne toujours ...
Pour un maximum de performances, un array raid5 4*750Go (2250Go) Il reste 2*250Go. Tu dois aussi faire une place pour le swap et pour /boot
Ne fais pas de l'espace restant une partition pour le système ou autre utilisation intensive, parce que chaque chaque accès boufferais les performances du raid5.
 

Un JBOD qui claque, doit y avoir moyen de faire quelque-chose avec photorec, mais remonter le filesystem ...

 
pour avoir vu de loin, de très loin, LVM, je dirais à 1ère vue rien, aucune différence ...
Reste que LVM est un driver du noyau Linux, JBOD un type de "raid" aussi implémenté matériellement ...
 
edit : ah si une différence quand même ...
en LVM tu dois créer des partitions qui seront utilisées par LVM, avec JBOD tu aggréges les disques direct, tu fais ensuite les partitions que tu veux ...
LVM rajoute une couche de "/dev/XXX" quoi ..