Bonjour,
j’ai voulu rajouter un HDD à ma grappe de 4 HDD en RAID5
malheureusement, le process de reshape est extremement lent! (>10 jours annoncé) malgré toutes les optimisations supposées accelerer le process!
je suis à une vitesse de 3500K/s, là où je pourrais attendre 30000!
Pendant ce reshaping, les perfs de mon NAS (OMV6/debian 11/intel I3/16Go RAM) tombent à zero
si je passe le reshape en frozen, je retrouve les perfs de lecture sur ma grappe…
je ne sais plus où trouver ce qui peut causer ce ralentissement
please help
Bonjour,
Quel est le volume de donnée considéré? Normalement l’ajout d’un disque à une grappe RAID 5 ne nécessite pas plus de temps que le remplacement d’un disque endommagé.
est-ce que le disque est le même que ceux de la grappe?
L’utilisation d’un disque par trop différent (pas la même taille, techno differente, temps d’accès par trop différent, etc.) peut effectivement poser problème.
Comment est architecturé ta machine? Ton RAID 5 ne prend en charge que les données? ou le système est aussi dessus?
initialement 4x4To que j essaie de passer à 5x4T
effectivement tous les HDD ne sont pas de la meme marque: 2 Toshiba, 2 seagate 1 WD. le nouveau etant un toshiba
l’OS est sur un SSD a part
j’ai une autre grappe en RAID1 qui fonctionne bien:
voici l output de mdstat:
cat /proc/mdstat
Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10]
md126 : active raid1 sdh[0] sdg[2]
3906886464 blocks super 1.2 [2/2] [UU]
bitmap: 2/30 pages [8KB], 65536KB chunkmd127 : active raid5 sdc[1] sdf[4] sdd[6] sde[5] sdb[7]
11720666112 blocks super 1.2 level 5, 512k chunk, algorithm 2 [5/5] [UUUUU]
[=>…] reshape = 7.0% (276492256/3906888704) finish=20794.2min speed=2909K/sec
bitmap: 0/30 pages [0KB], 65536KB chunk
les deux valeurs de chunk ne seraient elles pas en cause?
Bonjour,
Tu devrais regarder cet article ancien, mais je pense toujours valable :
Attention le RAID5 ne supporte la perte que d’un seul disque et les performances en écriture sont moins bonnes.
Zargos, on peut en faire quoi de ces valeurs de chunk ?
mes limites sont min 50000 / max 5000000
donc je ne pense plus qu’elles soient en cause, ça fait partie des points déjà modifiés à partir de cette page: https://www.cyberciti.biz/tips/linux-raid-increase-resync-rebuild-speed.html
Tu es sûr ? A ma connaissance le remplacement d’un disque ne requiert que de lire sur les autres disques et d’écrire sur le nouveau, alors que l’ajout d’un disque supplémentaire pour agrandir l’ensemble requiert de lire et réécrire tous les disques. Extrait de la page de manuel de mdadm :
Changing the number of active devices in a RAID5 or RAID6 is much more
effort. Every block in the array will need to be read and written back
to a new location.
Je suppose que cela provoque des déplacements des têtes incessants entre les positions de lecture et d’écriture et peut donc impacter fortement le débit effectif.
Oui effectivement, et probablement des recalcules de parité. utilisant souvent du RAID matériel, les temps sont différents.
Bonjour,
j’ai « résolu » mon probleme de vitesse de reshape en bootant sur l’image SystemRescue d’OMV.
j’ai multiplié x10 la vitesse comme ça et ai récupéré mon RAID en 12h!
Par contre, impossible de savoir pour quoi en boot normal j’avais cette reduction de perfs, dautant que maintenant, en fonctionnement normal, tout se comporte très bien, y compris en ecriture sur cette grappe
Pour un remplacement de disque, il faut recalculer les données manquantes à partir des données restantes et de la parité et les parités manquantes à partir des données, ce qui revient au même.
Pour un ajout de disque, il faut recalculer les parités en tenant compte de la nouvelle taille de bande.
A vue de nez, la charge CPU est similaire dans les deux cas.
Même version de noyau ?
Y avait-il des accès au RAID pendant le reshape ?
oui, je suppose pour le noyau
et non, aucun accès raid, j avais désactivé tous les services OMV
pour moi c 'est mystere total
Est-ce que le RAID était au minimum « utilisé » (système de fichiers monté, volume logique LVM activé…) ? Dans ce cas il se peut qu’il y ait une sorte de « verrou » pour garantir la cohérence des données pendant le reshape (pure spéculation de ma part).
oui, effectivement le systeme de fichiers etait monté…