1 votes

Le système de fichiers du système distant a disparu après "mdadm --grow 2 /dev/md0" ?

Hier, j'ai ajouté un deuxième disque dur de 500 Go à un système. Ce système a été installé en tant que système RAID-1 avec un seul disque, car je n'avais pas l'autre sous la main.

Après avoir finalement ajouté le deuxième disque, j'ai lancé "sfdisk -d /dev/sda | sfdisk --force /dev/sdb", comme je l'ai fait très souvent.

Puis j'ai exécuté "mdadm --add /dev/md0 /dev/sdb1", et le RAID a commencé à se synchroniser.

Une fois l'opération terminée, il s'est avéré que les nouvelles partitions avaient été ajoutées en tant que pièces de rechange, et non en tant que périphériques actifs. Cela semble s'être produit parce que le périphérique RAID 1 pensait qu'il n'avait de l'espace que pour un seul périphérique actif, en raison de l'installation étrange que j'ai faite.

Donc, aujourd'hui, j'ai lancé "mdadm --grow --raid-devices 2 /dev/md0" (notez que je n'ai pas mis un '=' avant le '2').

Immédiatement, tout mon système de fichiers a disparu !

Je suis toujours connecté à une session ssh, mais je suis limité aux commandes intégrées de bash, ce qui est plutôt pénible.

J'ai créé une commande bash-builtin-cat, et je peux toujours catcher certains fichiers. /proc/mdstat est parfait et indique que le nouveau disque est maintenant actif.

/var/log/messages (qui, bizarrement, est toujours accessible alors que tous les autres fichiers ne le sont pas) me donne des milliers de :

tentative d'accès au-delà de l'extrémité de l'appareil md0 : rw=0, want=868055984, limit=4

(le chiffre après "vouloir" varie). Les messages ont tous été générés en quelques secondes après l'exécution de mdadm --grow, puis se sont arrêtés.

Comme mentionné, il s'agit d'une machine distante.

  • Que s'est-il passé ici ?
  • Y a-t-il un moyen de défaire ce que --grow a fait ?
  • Puis-je retirer le nouveau disque du périphérique RAID en faisant simplement écho à d'obscurs fichiers /proc (puisque mdadm n'est plus trouvé) ?
  • Dois-je déclencher un redémarrage du SysRq, et espérer le meilleur ?

0 votes

Vous dites que /proc/mdstat semble correct - montre-t-il 2/2 périphériques ?

0 votes

Oui ! C'est ce que je ne comprends pas ! C'est aussi "synchronisé", et non plus "de réserve".

0voto

Eh bien, un redémarrage brutal a réglé le problème, bizarrement.

Après le redémarrage, l'ordinateur a démarré normalement, et maintenant il reconstruit à nouveau la matrice RAID 1, et le disque supplémentaire est marqué comme disque de rechange, à nouveau.

Il semble donc que la commande grow ait instantanément fait disparaître le système de fichiers et l'accès au disque - si rapidement que même les effets de la commande grow n'ont pas été écrits sur le disque.

Étrange.

EDITAR: Il s'est avéré que le disque qui contenait les données avait des secteurs défectueux, donc la première synchronisation initiale a échoué, et mdadm a mis le nouveau disque (pas complètement synchronisé) en mode "spare". Ma solution temporaire a été d'écrire des zéros sur les secteurs défectueux (ce que vous ne devriez pas faire !) en utilisant hdparm (google "hdparm write bad sectors"). Pour une raison étrange, cela a fonctionné (même si un peu de données a été perdu), et la matrice a réussi à terminer sa synchronisation initiale. Maintenant, je peux retirer le disque défectueux et synchroniser le nouveau disque avec un disque encore plus récent.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X