Demarrage lent après un rebuild d'un disque dur raid

Bonjour;

J’aurais une question bête.
Je m’entraine sur une VM Debian 11 avec plusieurs configurations RAID 1 et 5 (RAID Logiciel MDAM)
J’ai remarqué quand je supprime l’un des disques durs originaux qui étaient en RAID et je remets un nouveau disque dur en Raid, le démarrage est lent (plus 2 min) comparé au disque dur original.

Je voulais savoir c’est normal ou il y a un moyen de régler ce problème.

Mr_Hassan60

Bonour,

le disque supprimé, c’etait RAID 1 ou RAID 5?
dans les deux cas:
RAID 1: il fautr que le nouveau disque se synchronise avec l’autre disque.
RAID 5: il faut que le système reconstruise le RAID au complet (j’imagine que tu n’as que 3 disques?)

Ma dernière installation Debian 11 était que les disques était en RAID 5 (avec 3 disque).
Mais j’ai eu le même problème avec une installation RAID 1 avec 2 disque.

J’attend bien que les disques se synchronise à l’aide de la commande watch cat /proc/mdstat
avant de relancer un reboot de la VM.

Et tu n’as rien dans le syslog au demarrage qui t’indique uune erreur, un warning ou un messages quelconque pouvant s’y rapporter?

Est-ce un délai qui se produit à un moment donné du démarrage ou est-ce que toutes les étapes sont ralenties ?
Après le démarrage, le fonctionnement du système est-il également affecté ?

Quel que soit le niveau de RAID il suffit de resynchroniser le nouveau disque à partir des informations présentes sur les disques restants.

C’est au démarrage qui prend un moment avant d’arriver sur l’écran de connexion et il reste bloqué pendant 2-5 min avec ce message (ci-joint l’image).
image

« Gave up waiting for suspend/resume device » : le swap défini pour l’hibernation est introuvable. L’identifiant (UUID ou autre) spécifié dans /etc/initramfs-tools/conf.d/resume ne correspond pas avec le swap existant (vérifier avec blkid), ou le swap en question n’existe plus, ou n’est pas disponible (dans un périphérique qui n’est pas encore actif).
Le même problème peut se produire avec le swap défini dans /etc/fstab.

« /dev/md1: recovering journal » : le système de fichiers dans l’ensemble RAID n’a pas été démonté proprement lors de l’arrêt ou du redémarrage. C’est sytématique ? Ça reste combien de temps avant d’afficher la ligne suivante ?

« /dev/md1: recovering journal » : le système de fichiers dans l’ensemble RAID n’a pas été démonté proprement lors de l’arrêt ou du redémarrage. C’est sytématique ? Ça reste combien de temps avant d’afficher la ligne suivante ?"

Il reste bloqué pendant 2-5 min avant être dans l’écran de connexion.

Avant ou après avoir affiché « /dev/md1: clean, xx/xx files, xx/xx blocks » ?

après avoir afficher les messages d’erreurs « /dev/md1: clean, xx/xx files, xx/xx blocks ».

Ce n’est pas un message d’erreur mais un message d’état normal.
Donc ce n’est pas la réparation du système de fichiers qui prend tout ce temps. Que donne le démarrage en mode « recovery » via le sous-menu « Avancé/Advanced » de GRUB ?

Ce message a été signalé par la communauté et est temporairement masqué.

Ce message a été signalé par la communauté et est temporairement masqué.

Le temps de resynchronisation dépend de la taille de l’ensemble RAID mais pas de la taille des données utiles car à ma connaissance le RAID logiciel de Linux ne stocke pas d’information sur les blocs qui sont utilisés ou pas. Ça pourrait être pratique pourtant.

Absurde. Le volume de données à reconstruire dépend de la taille de l’ensemble RAID et non de la capacité du disque.

Merci pour le rappel @PascalHambourg, les réponses de fab qui ont été depuis modéré on été rédigé à l’aide d’une aide particulière et ne sont pas vraiement à prendre en compte.

Il ne le fait pas par défaut, mais je crois qu’il peut le faire avec une configuration particulière, mais encore faudrait-il digérer ce genre de dossier techniques (qui date tout de même de 2018):
https://raid.wiki.kernel.org/index.php/RAID_superblock_formats

il y a des information intéressante dans le chapitre 7 du document ci-dessous, notamment sur le fait de jouer sur le chunk size pour optimiser la rapidité:
https://wiki.deimos.fr/Optimisation_des_filesystems_extX_et_du_RAID_sous_Linux.html

Mais encore ? Le « write-intent bitmap » ne fait qu’enregistrer les blocs modifiés pour resynchroniser un disque qui n’est pas à jour sans le reconstruire, mais ça ne sert à rien dans le cas du remplacement par un nouveau disque.

Bonjour,

Désolé pour la réponse tardive, j’ai constaté une amélioration en réactivent le swap de mon disque sda.
Il est un peu plus rapide au démarrage mais toujours moins rapide qu’au démarrage du disque dur sda original.

Mahmood Hassan