Bonjour tous,
J'ai un petit serveur (perso) qui est monté en raid + lvm. Le raid qui m'intéresse est un raid5 sur 3 disques sata.
Suite à une petite coupure de courant, un disque n'est pas correctement remonté. Enfin si, mais mon raid tourne sur deux pattes seulement.
J'ai donc voulu reconstruire mon raid en ajoutant la partition, mais là l'ordi devient carrément inutilisable :
le load de la machine monte à quasi 4
et surtout, la reconstruction est super super lente, j'arrive pas à dépasser les 750ko/s et il m'indique de l'ordre de 5500 - 6000 minutes de reconstruction...
Comment on reconstruit un raid sans rendre la machine inutilisable et dans des temps corrects ? Genre une nuit si besoin, mais pas 3 jours.
J'ai essayé de jouer avec /proc/sys/dev/raid/speed_limit_min mais cela n'a aucun effet.
Voici quelques sorties pour infos.
partition déconnectée :
# mdadm --detail /dev/md2
/dev/md2:
Version : 0.90
Creation Time : Mon Jun 25 00:32:13 2007
Raid Level : raid5
Array Size : 483363456 (460.97 GiB 494.96 GB)
Used Dev Size : 241681728 (230.49 GiB 247.48 GB)
Raid Devices : 3
Total Devices : 2
Preferred Minor : 2
Persistence : Superblock is persistent
Intent Bitmap : Internal
Update Time : Tue Aug 2 09:14:35 2011
State : active, degraded
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
Layout : left-symmetric
Chunk Size : 64K
UUID : 7e6c101a:09efb900:6ad65a8a:45815ce7
Events : 0.85486
Number Major Minor RaidDevice State
0 0 0 0 removed
1 8 23 1 active sync /dev/sdb7
2 8 39 2 active sync /dev/sdc7
# cat /proc/mdstat
Personalities : [raid1] [raid6] [raid5] [raid4]
md2 : active raid5 sdb7[1] sdc7[2]
483363456 blocks level 5, 64k chunk, algorithm 2 [3/2] [_UU]
bitmap: 31/231 pages [124KB], 512KB chunk
# cat /proc/sys/dev/raid/speed_limit_min
50000
# cat /proc/sys/dev/raid/speed_limit_max
100000
Disque en cours de reconstruction :
# mdadm /dev/md2 --re-add /dev/sda7
mdadm: re-added /dev/sda7
# mdadm --detail /dev/md2
/dev/md2:
Version : 0.90
Creation Time : Mon Jun 25 00:32:13 2007
Raid Level : raid5
Array Size : 483363456 (460.97 GiB 494.96 GB)
Used Dev Size : 241681728 (230.49 GiB 247.48 GB)
Raid Devices : 3
Total Devices : 3
Preferred Minor : 2
Persistence : Superblock is persistent
Intent Bitmap : Internal
Update Time : Tue Aug 2 09:22:08 2011
State : active, degraded, recovering
Active Devices : 2
Working Devices : 3
Failed Devices : 0
Spare Devices : 1
Layout : left-symmetric
Chunk Size : 64K
Rebuild Status : 0% complete
UUID : 7e6c101a:09efb900:6ad65a8a:45815ce7
Events : 0.85765
Number Major Minor RaidDevice State
3 8 7 0 spare rebuilding /dev/sda7
1 8 23 1 active sync /dev/sdb7
2 8 39 2 active sync /dev/sdc7
# cat /proc/mdstat
Personalities : [raid1] [raid6] [raid5] [raid4]
md2 : active raid5 sda7[3] sdb7[1] sdc7[2]
483363456 blocks level 5, 64k chunk, algorithm 2 [3/2] [_UU]
[>....................] recovery = 0.0% (39680/241681728) finish=6140.3min speed=653K/sec
bitmap: 32/231 pages [128KB], 512KB chunk
Avez-vous des solutions, trucs, astuces, etc pour améliorer ce comportement ?
Merci par avance !
# changer de disque ou ne pas utiliser la machine pendant la reconstruction
Posté par NeoX . Évalué à 2.
si le disque a un defaut, il va falloir plusieurs tentative pour lire/ecrire dessus
=> ca fait monter les I/Owait et donc la charge du processeur (tu le vois dans top)
cela ralentit donc le processus de reconstruction.
sinon il semblerait que tu fasses ton RAID sur des partitions (numerotation 7 : sda7/sdb7/sdc7)
idealement, pour des questions de performances, il ne faudrait pas utiliser les disques sda/sdb/sdc pendant l'operation de reconstruction, car si les tetes bougent pour aller ailleurs (sur sda/sdb/sdc partition 1 à 6) cela genere encore des I/O Waits
[^] # Re: changer de disque ou ne pas utiliser la machine pendant la reconstruction
Posté par CrEv (site web personnel) . Évalué à 3.
Ha oui, c'est vrai que j'ai pas précisé, au dessus de mon raid, j'ai deux vm (kvm) qui tournent à travers un lvm (les vm font office de serveur web / mail entre autre, donc si je peux les garder en route...)
Donc si je coupais mes vm et arrêtais un max de service ce serait surement plus rapide ? La différence peut être importante ?
Question subsidiaire, on peut "monitorer" les IO pour savoir un peu ce que ça donne (pour savoir si la lenteur vient des IO) ?
[^] # Re: changer de disque ou ne pas utiliser la machine pendant la reconstruction
Posté par GG (site web personnel) . Évalué à 1.
Bonjour,
Ce sont de très bons utilitaires, dépendant parfois d'un noyau pas trop vieux (je crois que iotop ne tourne pas sur 2.6.26).
Bon courage
G
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: changer de disque ou ne pas utiliser la machine pendant la reconstruction
Posté par CrEv (site web personnel) . Évalué à 2.
Merci pour ces infos, je n'avais jamais utilisé, c'est pas mal du tout (plus sympa que top)
Par contre, au final je ne comprend rien...
lorsque je relance la construction du raid (que j'ajoute ma partition manquante) :
0.8%us, 1.0%sy, 0.0%ni, 29.3%id, 68.9%wa
Mais les services deviennent inutilisables :(
Faut-il arrêter tous mes services et démonter tout ce qui est au dessus du raid (démonter les partitions lvm) pour améliorer les choses ?
[^] # Re: changer de disque ou ne pas utiliser la machine pendant la reconstruction
Posté par NeoX . Évalué à 2.
avec 70% du temps en IOwait, ton CPU passe son temps à attendre apres un peripherique.
mais ce n'est peut-etre pas un peripherique disque dur
ce qui fait que ca n'apparait pas dans IOtop
ou alors c'est peut-etre bien le disque qui pedale car la coupure l'aurait fait sauter, du coup il doit tenter plusieurs fois pour avoir une ecriture ou une lecture
[^] # Re: changer de disque ou ne pas utiliser la machine pendant la reconstruction
Posté par Lucky Seven . Évalué à 0.
La reconstruction d'un RAID 5 demande de gros calculs, 3 jours ne me parait pas excessif.
[^] # Re: changer de disque ou ne pas utiliser la machine pendant la reconstruction
Posté par ymorin . Évalué à 1.
Tout à fait d'accord. Surtout, ça dépend du CPU et de sa vitesse. Sur mon Core2-Quad @ 2.93GHz, reconstruire un RAID 5 de 2+1 disques de 320 GiB (soit 640 GiB utiles) a pris plus de 30h.
# Brutal
Posté par Mikis . Évalué à 2.
Je commencerai par faire une sauvegarde complète. Lors de la reconstruction, les disques travaillent beaucoup, il y a des risques qu'un disque lâche (même si le risque est plus faible que lorsque le problème "raid" est provoqué par un disque qui a lâché).
Puis les sauvegardes, c'est bien. ;)
Ensuite, puisque la reconstruction est trèèèèèès lente, je repartirai à zéro et je réintègrerai les données précédemment sauvegardées.
# suite
Posté par CrEv (site web personnel) . Évalué à 2.
J'ai avancé un peu : j'ai coupé tous les services et démonté les partitions basés sur mon raid5
J'ai lancé la reconstruction ... et c'est toujours aussi lent :-(
top me montre qu'il ne fait rien...
Quelqu'un aurait une autre idée pour accélérer tout ça, disons pour que ça travail un peu quoi, là on à l'impression qu'il ne fait rien du tout...
Contrairement aux premières tentatives, le wait du proc est toujours inférieur à 3% (des piques entre 2 et 3).
Merci d'avance !
[^] # Re: suite
Posté par maxix . Évalué à 2.
Monitore l'évolution du nombre de secteurs défectueux avec smartmontools?
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.