Reprise du message précédent :

Ben non justement, ça alterne, ça parallélise pas.

Si ça parallélisait les 2 loupiotes seraient actives en même temps.

Planète debian.org sinon

par parallèle on veut dire lecture simultanée sur les disques

c'est quand même pas clair

dmraid fait pas de load balancing, c'est le driver fake raid en fait, dont je sais pas trop ce que c'est censé faire à part que ça rend le raid lisible aussi pour windows par exemple car c'est en partie géré par le bios.

mdraid fait du load balancing, mais apparement n'améliorerait que les temps d'accès en lisant en séquentiel depuis les deux disques, mais pas en parallèle comme le raid 0.

par contre éssaye de lire deux fichier en même temps, c'est possible qu'il lise sur les deux disques en même temps.
d'après ce que j'ai lu ils considèrent que pour les lectures séquentielles de blocs lire sur un disque puis l'autre ne serait pas plus performant, car il faudrait sauter des blocs, et ça reviendrait au même.

c'est ce que je disais au dessus, en fait il faudrait pour du séquentiel sur un fichier, qu'il lise plus intelligement en anticipant.

Fake RAID c'est pour les "contrôleur RAID" intégrés aux mobales, c'est de la merde en barre pour pouvoir faire du RAID soft sous Win.

bon j'ai fait le test en fesant
cat fichier1 > /dev/null &
cat fichier2 > /dev/null &
dstat -D sda,sdb,hd0

et ça donne

donc il lit bien en parallèle sur les deux disques, ce qui reste très intéressant pour un OS multitache
par contre pour un cat sur un seul fichier il alterne sur les deux disques plus ou moins au hasard en apparence
il faudrait qu'il puisse savoir plus en avance ce qu'il doit lire pour pouvoir optimiser et minimiser les sauts de têtes.

par contre sur un système de fichier très fragmenté je pense que le raid1 à surement un avantage sur le raid0 du coup.

Et sur un raid1 ou raid0 de SSD on arriverait surement au même résultat pour les deux en temps d'accès et débit.

 
C'est pas faux ...    
Pas encore sorti du we meuha ...    

 
Comme quoi, faut jamais utiliser fsck

il me semble pas que fsck défragmente

bon le système est réellement plus rapide à charger en raid1, c'est indéniable, ça va bien plus vite qu'avec un seul disque

surtout que les disques sont réglés en mode silencieux, donc avec des déplacements de tête plus lents, ce qui avec un disque se fait sentir.

enfin ça montre que si le système savait demander au fs de réorganiser les fichiers lus au boot de manière séquentielle, le boot serait surement plus rapide.

petite precision, tout est sur lvm y compris la partition de boot, et comme j'ai une pseudo partition avec juste grub et une iso bootable avec grub, pour faire du pseudo chainload vers le vrai linux j'utilise :
 
menuentry "load linux" {
 configfile (vdrbox-linux)/boot/grub/grub.cfg
}
 
car grub ne peut pas s'installer dans volume logique lvm

Grub2 peut le faire

je parle de grub2 en fait là

grub 1 ou 2 ne peut pas s'installer dans du LVM, car il n'y a pas de bootsecteur dans les partitions LVM. Si grub s'installe dans le premier secteur il va flinguer direct le systeme de fichier je pense, et de toutes façons il veut pas.

secondement, ( ) ,
pour pouvoir lire du raid ou lvm, grub à besoin d'adresser le disque de façon logique et non physique, et donc d'avoir sous la main ses modules raid et lvm et en fait soit il les stocke dans la partition qu'il sait accéder physiquement, genre un systeme de fichier dans une partition msdos ou gpt, ou alors il les lit depuis une image core.img qu'il met juste après le mbr si il a la place.
Donc tu peux booter sur un disque ou /boot est sur LVM, à la condition que tu aies laissé un espace entre le MBR et la premiere partition avec une table de partition msdos.
Ou alors avec gpt c'est plus clair, grub "s'embeded" dans une petite partition de quelques mo que tu vas créer et sur laquelle tu vas mettre le drapeau biosboot.

Sur LVM grub pourra jamais trouver core.img vu qu'il a besoin des modules de core.img pour le trouver sur LVM

 
Franchement le raid soft + lvm j'ai laissé tombé sur les serveurs. Ca n'apporte franchement pas grand chose et quand ca crash, c'est franchement lourd de tout récupérer. Je me limite simplement au raid soft quand j'en ai besoin avec un /boot / (et un /var et/ou /usr suivant les besoins).

maintenant que grub peut booter avec le dossier /boot sur lvm faire soft raid plus lvm c'est plutot simple
 
suffit de faire une petite partition gpt de 8mo pour grub, puis une partition de tout le disque, ensuite la déclarer en raid, puis créer lvm sur le device raid et ça roule
je vois pas quels soucis je peux avoir en cas de crash
avec un livecd il suffit d'installer les outils mdraid ou juste lvm pour voir apparaitre ses devices lvm

Je parle surtout de la maintenance en cas de crash et tout bonnement de l'intéret au final. Pour des serveurs en prod, j'évite d'ajouter de la compléxité quand je peux.

quel type de crash ?

sinon c'est sur que si t'as pas besoin de redimentionner ou ajouter de disque ça sert à rien de s'embeter

recuperer/repararer le raid et les données

Oui mais comme tu utilises du raid même soft, je vois pas comme ça quel type de crash peut imposer une récupération de données autre que changer le disque défaillant et reconstruire le raid.

bah un bug soft justement ...
 
ou pire, un driver pas top au point qui fout la merde ...
 
bon, depuis qqs années, ce n'est plus vraiment d'actualité car la politique au niveau test du noyau s'est grandement améliorée, mais au début du 2.6 c'était un peu la fête ...

 
secteurs defectueux, erreur io sur les deux disques, etc

bon j'ai un disque qui merdoie et ça me pose des soucis
mais c'est peut être du au fait que j'ai un peu oublié comment utiliser mdadm
 

ça existe des raid 1 en remote ?
 
Ou du moins des pseudos raid 1 au niveau fichier et pas bloc ?
 
J'ai un backintime qui avec un backup local et remote qui fait office de.
Mais je me demandais si il y avait pas un peu mieux.