Wie kann ein mdadm-Array auf einem Synology NAS mit Laufwerk im Status "E" wiederhergestellt werden?


12

Synology verfügt über eine angepasste Version des md-Treibers und der mdadm-Toolsets, die der Struktur rdev-> flags im Kernel ein 'DriveError'-Flag hinzufügen.

Nettoeffekt - Wenn Sie das Pech haben, einen Array-Fehler (erstes Laufwerk) in Verbindung mit einem Fehler auf einem zweiten Laufwerk zu bekommen, kann das Array das Array nicht reparieren / rekonstruieren, obwohl Lesevorgänge vom Laufwerk funktionieren fein.

An diesem Punkt bin ich aus Sicht DIESES Arrays nicht wirklich besorgt über diese Frage, da ich bereits Inhalte abgerufen habe und beabsichtige, sie zu rekonstruieren, sondern eher, weil ich in Zukunft einen Lösungspfad dafür haben möchte , da es das zweite Mal ist, dass ich davon gebissen wurde, und ich weiß, dass ich andere gesehen habe, die ähnliche Fragen in Foren gestellt haben.

Die Synologieunterstützung war weniger hilfreich (und reagierte größtenteils nicht) und gibt keinerlei Informationen zum Umgang mit den Raidsets auf der Box weiter.

Inhalt von / proc / mdstat:

ds1512-ent> cat /proc/mdstat 
Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] 
md2 : active raid5 sdb5[1] sda5[5](S) sde5[4](E) sdd5[3] sdc5[2]
      11702126592 blocks super 1.2 level 5, 64k chunk, algorithm 2 [5/4] [_UUUE]

md1 : active raid1 sdb2[1] sdd2[3] sdc2[2] sde2[4] sda2[0]
      2097088 blocks [5/5] [UUUUU]

md0 : active raid1 sdb1[1] sdd1[3] sdc1[2] sde1[4] sda1[0]
      2490176 blocks [5/5] [UUUUU]

unused devices: <none>

Status von einem mdadm --detail / dev / md2:

/dev/md2:
        Version : 1.2
  Creation Time : Tue Aug  7 18:51:30 2012
     Raid Level : raid5
     Array Size : 11702126592 (11160.02 GiB 11982.98 GB)
  Used Dev Size : 2925531648 (2790.00 GiB 2995.74 GB)
   Raid Devices : 5
  Total Devices : 5
    Persistence : Superblock is persistent

    Update Time : Fri Jan 17 20:48:12 2014
          State : clean, degraded
 Active Devices : 4
Working Devices : 5
 Failed Devices : 0
  Spare Devices : 1

         Layout : left-symmetric
     Chunk Size : 64K

           Name : MyStorage:2
           UUID : cbfdc4d8:3b78a6dd:49991e1a:2c2dc81f
         Events : 427234

    Number   Major   Minor   RaidDevice State
       0       0        0        0      removed
       1       8       21        1      active sync   /dev/sdb5
       2       8       37        2      active sync   /dev/sdc5
       3       8       53        3      active sync   /dev/sdd5
       4       8       69        4      active sync   /dev/sde5

       5       8        5        -      spare   /dev/sda5

Wie Sie sehen können, wurde / dev / sda5 dem Array erneut hinzugefügt. (Es war das Laufwerk, das völlig ausgefallen ist) - aber obwohl md das Laufwerk als Ersatzlaufwerk ansieht, wird es nicht neu erstellt. / dev / sde5 ist in diesem Fall das Problemlaufwerk mit dem Status (E) DiskError.

Ich habe versucht, das md-Gerät anzuhalten, die Kraft wieder zusammenzusetzen, sda5 vom Gerät zu entfernen / zu lesen / etc. Keine Verhaltensänderung.

Ich konnte das Array mit dem folgenden Befehl vollständig neu erstellen:

mdadm --stop /dev/md2
mdadm --verbose \
   --create /dev/md2 --chunk=64 --level=5 \
   --raid-devices=5 missing /dev/sdb5 /dev/sdc5 /dev/sdd5 /dev/sde5

das brachte das Array zurück in diesen Zustand:

md2 : active raid5 sde5[4] sdd5[3] sdc5[2] sdb5[1]
      11702126592 blocks super 1.2 level 5, 64k chunk, algorithm 2 [5/4] [_UUUU]

Ich habe dann / dev / sda5 erneut hinzugefügt:

mdadm --manage /dev/md2 --add /dev/sda5

Danach begann ein Umbau:

md2 : active raid5 sda5[5] sde5[4] sdd5[3] sdc5[2] sdb5[1]
      11702126592 blocks super 1.2 level 5, 64k chunk, algorithm 2 [5/4] [_UUUU]
      [>....................]  recovery =  0.1% (4569508/2925531648) finish=908.3min speed=53595K/sec

Beachten Sie, dass die Position des "fehlenden" Laufwerks genau mit der Position des fehlenden Steckplatzes übereinstimmt.

Sobald dies abgeschlossen ist, werde ich wahrscheinlich das fragliche Laufwerk ziehen und es erneut erstellen lassen.

Ich suche nach Vorschlägen, ob es einen "weniger beängstigenden" Weg gibt, diese Reparatur durchzuführen - oder ob jemand diese Erfahrung mit einem Synology-Array gemacht hat und weiß, wie man es zwingt, es neu zu erstellen, außer das md-Gerät offline zu schalten und Neuerstellung des Arrays von Grund auf neu.


Ich befinde mich in einer ähnlichen Situation. Haben Sie das erfolgreich gelöst?
Dvorak

Ja, ich konnte das Array gemäß den obigen Schritten neu erstellen. Ich habe es anschließend gelöscht und von R5 auf R6 geändert - da ich zu diesem Zeitpunkt ernsthaft unzufrieden bin mit dem Verhalten von Synology "Tank the Whole Array", bei dem ich sicherstellen wollte, dass mehr als ein Laufwerk ausfällt ". In unserem Fall hat das zweite Laufwerk mit dem Fehler "Glitch" erweiterte Smart-Tests ohne ein einziges Problem bestanden.
Nathan Neulinger

Vielen Dank für die hilfreiche Anleitung. Ich bin nicht zu zuversichtlich, mit all dem herumzuspielen, ich bin kein Raid-Spezialist. Ich habe jetzt das gleiche Problem, aber in meinem Fall habe ich ein RAID 1-Array mit einer Festplatte (/ dev / md3), wobei / dev / sde3 mit dem gefürchteten [E] markiert ist. Ich gehe davon aus, dass es mir möglich sein sollte, die gleichen Schritte wie Sie auszuführen, aber da dies die einzelne Festplatte des Arrays ist, weiß ich nicht, was es tun wird ;-). Auf jeden Fall schlägt der Befehl mdadm --stop / dev / md3 fehl (Gerät oder Ressource belegt). Ich denke, ich werde ein bisschen länger
googeln

Wenn Sie das Array nicht stoppen können, klingt es so, als würde es von einem Benutzer verwendet, dh es ist gemountet, oder es wird eine andere Aufgabe für dieses Gerät ausgeführt.
Nathan Neulinger

2
Zum Glück hat mir Synology geholfen, das Problem zu beheben. Sie waren so freundlich, mir die Befehle zu geben, die sie ausführten. Ich habe die Informationen in meinem Blog veröffentlicht, falls jemand anderes auf dieses Problem stößt
dSebastien

Antworten:


3

Nur eine Ergänzung zu der Lösung, die ich gefunden habe, nachdem ich das gleiche Problem hatte. Ich folgte dem Blog-Beitrag von dSebastien zum Neuerstellen des Arrays:

Ich fand, dass diese Methode zum Neuerstellen des Arrays besser funktionierte als diese obige Methode. Nach dem erneuten Erstellen des Arrays wurde das Volume jedoch immer noch nicht auf der Weboberfläche angezeigt. Keine meiner LUNs zeigte sich. Grundsätzlich wird ein neues Array angezeigt, für das nichts konfiguriert ist. Ich habe den Synology-Support kontaktiert und sie haben sich entfernt, um das Problem zu beheben. Leider haben sie sich entfernt, während ich nicht an der Konsole war. Ich habe es jedoch geschafft, die Sitzung festzuhalten, und habe durchgesehen, was sie getan haben. Beim Versuch, einige meiner Daten wiederherzustellen, stürzte das Laufwerk erneut ab und ich war wieder in der gleichen Situation. Ich habe das Array wie in dSebastiens Blog neu erstellt und dann die Synologiesitzung durchgesehen, um das Update durchzuführen. Nachdem ich die folgenden Befehle ausgeführt hatte, wurden mein Array und meine LUNs auf der Weboberfläche angezeigt, und ich konnte mit ihnen arbeiten. Ich habe praktisch keine Erfahrung mit Linux, aber dies waren die Befehle, die ich in meiner Situation ausgeführt habe. Ich hoffe, dies kann jemand anderem helfen, aber bitte verwenden Sie dies auf eigenes Risiko. Wenden Sie sich am besten an den Synology-Support, damit dieser das Problem für Sie behebt, da sich diese Situation möglicherweise von Ihrer unterscheidet

DiskStation> synocheckiscsitrg
synocheckiscsitrg: Pass 

DiskStation> synocheckshare
synocheckshare: Pass SYNOICheckShare()
synocheckshare: Pass SYNOICheckShareExt()
synocheckshare: Pass SYNOICheckServiceLink()
synocheckshare: Pass SYNOICheckAutoDecrypt()
synocheckshare: Pass SYNOIServiceShareEnableDefaultDS()

DiskStation> spacetool --synoblock-enum
****** Syno-Block of /dev/sda ******
//I've removed the output. This should display info about each disk in your array

DiskStation> vgchange -ay
  # logical volume(s) in volume group "vg1" now active

DiskStation> dd if=/dev/vg1/syno_vg_reserved_area of=/root/reserved_area.img
24576+0 records in
24576+0 records out

DiskStation> synospace --map_file -d
Success to dump space info into '/etc/space,/tmp/space'

DiskStation> synocheckshare
synocheckshare: Pass SYNOICheckShare()
synocheckshare: Pass SYNOICheckShareExt()
synocheckshare: Pass SYNOICheckServiceLink()
synocheckshare: Pass SYNOICheckAutoDecrypt()
synocheckshare: Pass SYNOIServiceShareEnableDefaultDS()

DiskStation> synocheckiscsitrg
synocheckiscsitrg: Not Pass, # conflict 

DiskStation> synocheckiscsitrg
synocheckiscsitrg: Pass 

1

Ein weiterer Zusatz: Ich habe ein sehr ähnliches Problem mit meinem Gerät mit einer Festplatte / RAID-Stufe 0 festgestellt.

Die Synologieunterstützung war sehr hilfreich und stellte mein Gerät wieder her. Folgendes ist passiert, hoffe, dies hilft anderen:

Meine Festplatte hatte Lesefehler in einem bestimmten Block. Die Meldungen im Systemprotokoll ( dmesg) lauteten:

[4421039.097278] ata1.00: read unc at 105370360
[4421039.101579] lba 105370360 start 9437184 end 5860528064
[4421039.106917] sda3 auto_remap 0
[4421039.110097] ata1.00: exception Emask 0x0 SAct 0x2 SErr 0x0 action 0x6
[4421039.116744] ata1.00: edma_err_cause=00000084 pp_flags=00000003, dev error, EDMA self-disable
[4421039.125410] ata1.00: failed command: READ FPDMA QUEUED
[4421039.130767] ata1.00: cmd 60/00:08:b8:d2:47/02:00:06:00:00/40 tag 1 ncq 262144 in
[4421039.130772]          res 41/40:00:f8:d2:47/00:00:06:00:00/40 Emask 0x409 (media error) <F>
[4421039.146855] ata1.00: status: { DRDY ERR }
[4421039.151064] ata1.00: error: { UNC }
[4421039.154758] ata1: hard resetting link
[4421039.667234] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl F300)
[4421039.887286] ata1.00: configured for UDMA/133
[4421039.891777] ata1: UNC RTF LBA Restored
[4421039.895745] ata1: EH complete

Einige Sekunden später erhielt ich die schreckliche Volume 1 has crashedMail von meinem Gerät.

- Haftungsausschluss: Ersetzen Sie unbedingt den Gerätenamen durch Ihren und kopieren Sie diese Befehle nicht einfach und fügen Sie sie ein, da dies die Situation verschlimmern könnte! - -

Nachdem ich smb gestoppt hatte, konnte ich die Partition schreibgeschützt erneut mounten und e2fsk mit badblocks check ( -c) ausführen :

umount /dev/md2
e2fsck -C 0 -v -f -c /dev/md2

(Man könnte auch verwenden e2fsck -C 0 -p -v -f -c /dev/md2, um so unbeaufsichtigt wie möglich zu laufen, obwohl dies in meinem Fall nicht funktioniert hat, da die Fehler manuell behoben werden mussten. Also musste ich e2fsck neu starten. Fazit: -p macht in nicht viel Sinn Fall eines Festplattenfehlers)

Obwohl e2fsck in der Lage war, die Fehler zu beheben und smartctl auch keinen Anstieg von Raw_Read_Error_Rate mehr zeigte, wurde das Volume vom Gerät im Lese- / Schreibmodus immer noch nicht bereitgestellt. DSM zeigte immer noch "Lautstärke abgestürzt"

Also habe ich mit Unterstützung ein Ticket geöffnet. Es hat eine ganze Weile gedauert, bis die Dinge in Gang kamen, aber am Ende haben sie das Problem behoben, indem sie das RAID-Array neu erstellt haben mit:

synospace --stop-all-spaces
syno_poweroff_task -d 
mdadm -Sf /dev/md2
mdadm -AfR /dev/md2 /dev/sda3

Überprüfen Sie unbedingt Ihre Gerätenamen ( /dev/mdXund /dev/sdaX), bevor Sie etwas unternehmen. cat /proc/mdstatzeigt die relevanten Informationen.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.