Comment forcer mdadm à arrêter la matrice RAID5?


6

j'ai /dev/md127 RAID5 constitué de quatre disques. J'ai réussi à les supprimer à chaud du tableau et actuellement /dev/md127 n'a pas de lecteur:

cat /proc/mdstat Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] md0 : active raid1 sdd1[0] sda1[1]
      304052032 blocks super 1.2 [2/2] [UU]

md1 : active raid0 sda5[1] sdd5[0]
      16770048 blocks super 1.2 512k chunks

md127 : active raid5 super 1.2 level 5, 512k chunk, algorithm 2 [4/0] [____]

unused devices: <none>

et

mdadm --detail /dev/md127
/dev/md127:
        Version : 1.2
  Creation Time : Thu Sep  6 10:39:57 2012
     Raid Level : raid5
     Array Size : 8790402048 (8383.18 GiB 9001.37 GB)
  Used Dev Size : 2930134016 (2794.39 GiB 3000.46 GB)
   Raid Devices : 4
  Total Devices : 0
    Persistence : Superblock is persistent

    Update Time : Fri Sep  7 17:19:47 2012
          State : clean, FAILED
 Active Devices : 0
Working Devices : 0
 Failed Devices : 0
  Spare Devices : 0

         Layout : left-symmetric
     Chunk Size : 512K

    Number   Major   Minor   RaidDevice State
       0       0        0        0      removed
       1       0        0        1      removed
       2       0        0        2      removed
       3       0        0        3      removed

J'ai essayé de faire mdadm --stop /dev/md127 mais:

mdadm --stop /dev/md127
mdadm: Cannot get exclusive access to /dev/md127:Perhaps a running process, mounted filesystem or active volume group?

Je me suis assuré qu’il soit démonté, umount -l /dev/md127 et a confirmé qu'il est bien démonté:

umount /dev/md127
umount: /dev/md127: not mounted

J'ai essayé de mettre à zéro les superblocs de chaque lecteur et je reçois (pour chaque lecteur):

mdadm --zero-superblock /dev/sde1
mdadm: Unrecognised md component device - /dev/sde1

Voici la sortie de lsof | grep md127:

lsof|grep md127
md127_rai  276       root  cwd       DIR                9,0          4096          2 /
md127_rai  276       root  rtd       DIR                9,0          4096          2 /
md127_rai  276       root  txt   unknown                                             /proc/276/exe

Que puis-je faire d'autre? LVM n’est même pas installé, donc cela ne peut pas être un facteur.


Après avoir beaucoup fouillé, j'ai finalement trouvé ce qui m'empêchait d'arrêter le tableau. C'était un processus SAMBA. Après le service smbd stop J'ai pu arrêter le tableau. C’est étrange cependant, car même si le tableau a été monté et partagé via SAMBA à un moment donné, j’ai essayé de l’arrêter, il était déjà démonté.


À ce stade, je pense qu’il est prudent d’utiliser le --force option si vous ne l'avez pas déjà essayé. Aussi, quel est le processus 276 sur votre système? [mdadm] ?
Darth Android

Cela ne fonctionne pas, je reçois le même message: "mdadm: impossible d'obtenir un accès exclusif à / dev / md127: peut-être un processus en cours d'exécution, un système de fichiers monté ou un groupe de volumes actif?"
matt

1
sudo fuser -vm /dev/md127 pourrait montrer quel processus a un handle sur le tableau.
Nick Alexander

Réponses:


5

Je me rends compte que c’est une vieille question et que l’affiche originale pensait que SAMBA était le problème, mais j’ai rencontré exactement le même problème et je pense que très probablement le problème n’était pas SAMBA ne pas montrer dans le lsof sortie, mais l’utilisateur se trouvait déjà dans le répertoire du point de montage RAID lorsqu’il est passé en mode root ou a fait un sudo.

Dans mon cas, le problème était que j'ai démarré mon shell root alors que mon utilisateur habituel se trouvait dans un répertoire situé sur ce répertoire monté. /dev/md127 conduire.

user1@comp1:/mnt/md127_content/something$ su -
root@comp1:~# umount /dev/md127
umount: /dev/md127: target is busy

Voici la sortie de lsof dans mon cas:

root@comp1:root@comp1:~# lsof | grep /dev/md127
md127_rai  145            root  cwd       DIR      253,0     4096          2 /
md127_rai  145            root  rtd       DIR      253,0     4096          2 /
md127_rai  145            root  txt   unknown                                /proc/145/exe

Même si lsof | grep md125 n'a pas montré de processus sauf [md127_raid1], Je ne pouvais pas démonter /dev/md127. Et tandis que umount -l /dev/md127 se cache /dev/md127 de la sortie de mount, le lecteur est apparemment toujours occupé, et quand mdadm --stop /dev/md127 est tenté, la même erreur est affichée:

mdadm: Cannot get exclusive access to /dev/md127:Perhaps a running process, mounted filesystem or active volume group?

SOLUTION est simple: vérifiez si des utilisateurs connectés se trouvent toujours dans un répertoire de ce lecteur. En particulier, vérifiez si le shell racine que vous utilisez a été démarré alors que le répertoire actuel de votre utilisateur habituel se trouvait sur ce lecteur. Basculez vers le shell de cet utilisateur (peut-être juste exit votre racine doit), déplacez-vous ailleurs, et umount et mdadm --stop marchera:

root@comp1:~# exit
user1@comp1:/mnt/md127_content/something$ cd /
user1@comp1:/$ su -
root@comp1:~# umount /dev/md127
root@comp1:~# mdadm --stop /dev/md127
mdadm: stopped /dev/md127

@ sd1074 ​​Vous êtes peut-être sur quelque chose, mais je ne suis pas sûr que mon problème soit causé par le shell root qui a été créé à partir du chemin en question. shell racine à nouveau et alors seulement arrêter le tableau. Ce qui est possible, mais peu probable. Je pense que cette réponse acceptable devrait montrer comment déterminer quel processus bloque l’arrêt du tableau mdadm. lsof clairement échoue ici pour une raison quelconque.
matt

@ sd1074 ​​Si vous avez un scénario de test reproductible, pouvez-vous vérifier si l'un des périphériques utilisés en tant que composant de tableau mdadm possède des fichiers ouverts signalés par lsof? (Vous devez comparer les chiffres rapportés par lsof dans la colonne DEVICE par rapport aux nombres mineurs / majeurs de ces périphériques).
matt

1
@matt, j'ai gardé le journal de mes aventures avec ce raid. J'ai ajouté la sortie de lsof à ma réponse.
sd1074

@matt Bravo d'être revenu sur cette question près de 3 ans plus tard!
JakeGould

Deux ans plus tard, le problème me frappa à nouveau et je peux maintenant confirmer que c’est la cause d’un appareil paresseusement démonté ( umount -l /dev/md127 ) ET processus bash avec le répertoire de travail actuel toujours quelque part dans le système de fichiers monté (maintenant paresseusement démonté). Pour trouver quel processus est exactement responsable du problème, vérifiez cette question: unix.stackexchange.com/q/345422/59666
matt

1

Je rencontrais des problèmes similaires mais je n'avais aucun moyen de monter le périphérique RAID. Arrêter SAMBA n'a pas semblé aider non plus. lsof n'a rien montré.

Tout a juste abouti à:

# mdadm --stop /dev/md2
mdadm: Cannot get exclusive access to /dev/md2:Perhaps a running process, mounted filesystem or active volume group?

Ce qui a finalement résolu le problème pour moi, c’était de me rappeler qu’il s’agissait d’une partition swap. swapoff /dev/md2 - cela m'a permis de mdadm --stop /dev/md2 avec succès.


1

Si vous utilisez LVM en plus de mdadm, LVM ne supprimera parfois pas les périphériques Device Mapper lors de la désactivation du groupe de volumes. Vous pouvez le supprimer manuellement.

  1. Assurez-vous qu'il n'y a rien dans la sortie de sudo vgdisplay.
  2. Regarder dans /dev/mapper/. En dehors de la control fichier, il devrait y avoir un périphérique Device Mapper nommé d'après votre groupe de volumes, par exemple. VolGroupArray-name.
  3. Courir sudo dmsetup remove VolGroupArray-name (en remplaçant VolGroupArray-name avec le nom du périphérique Device Mapper).
  4. Vous devriez maintenant pouvoir courir sudo mdadm --stop /dev/md0 (ou quel que soit le nom du mdadm l'appareil est).
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.