TS-431: Disks unmounted und Examination failed

Liebes Forum,

ich wende mich heute Euch mit einem Problem, was ich mit meinem NAS 431 (QT 4.2 20151118) habe. Eins vorneweg, ich bin ein relativer Newbie und habe zwar ein hohes Interesse, aber nicht viel Ahnung von der Materie (ich hoffe von daher auch, dass hier das richtige Unterforum für diese Frage ist).

Was ist passiert:
Im NAS liefen zwei WD RED 3TB Platten im RAID 1 Betrieb. Da der Speicherplatz eng wurde, habe ich eine 3. Platte desselben Typs erworben und sie eingebaut. Das NAS initialisierte daraufhin die on-the-fly Migration in ein RAID 5, welcher am nächsten Morgen erfolgreich (dachte ich) abgeschlossen war. Ich habe das NAS dann heruntergefahren.

Beim Booten nun aber meldet mir das NAS, dass der Status des Volumes „unmounted“ sei. Einen Systemcheck kann ich zwar starten, dieser wird aber nach Sekunden schon mit der Meldung „Examination failed“ abgebrochen. Die Platten zeigen im Speichermanager erst einmal keine Auffäligkeiten, sie sind alle grün und (vordergründig) in Ordnung. In den Systemereignissprotokollen finde ich auch keine näheren Angaben, dort sind nur die Ereignisse seit dem aktuellen Reboot aufgelistet.

Eine kurze Forumsuche zu diesem Thema brachte zwar immer wieder das Thema „Examination failed (cannot unmount disk)“ auf. Ich glaube aber, dass dies ein anderes Problem ist, bei mir fehlt der Part in Klammern und meine Disks sind ja schon unmounted.
Ich habe per SSH nun auch Zugriff auf die Kommandozeile des NAS, aber nicht viel Ahnung, was ich dort bewerkstelligen kann und was mir die Angaben dort sagen. Die z.B. häufig vorgeschlagene „cat /proc/mtstat“ gibt mir dieses aus:

Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] [multipath]
md1 : active raid5 sda3[0] sdc3[3] sdb3[2]
      5840623232 blocks super 1.0 level 5, 64k chunk, algorithm 2 [3/3] [UUU]


md256 : active raid1 sdc2[2](S) sdb2[1] sda2[0]
      530112 blocks super 1.0 [2/2] [UU]
      bitmap: 0/1 pages [0KB], 65536KB chunk


md13 : active raid1 sda4[0] sdc4[24] sdb4[25]
      458880 blocks super 1.0 [24/3] [UUU_____________________]
      bitmap: 1/1 pages [4KB], 65536KB chunk


md9 : active raid1 sda1[0] sdc1[24] sdb1[25]
      530048 blocks super 1.0 [24/3] [UUU_____________________]
      bitmap: 1/1 pages [4KB], 65536KB chunk


unused devices: <none>

Ich wäre also um jede (kleine und große) Hilfestellung dankbar, ob und wie ich mein System wieder ans Laufen bekomme.

PS. Ein Backup ist leider nicht vorhanden, die Anschaffung einer großen externen 6TB Platte war zwar geplant, aber noch nicht realisiert.

Update & bump

Nachdem ich mich nun einige Tage mit dem Problem befasst habe, gibt es von meiner Seite ein kleines Update mit neuen Informationen (und neuen Fragen). Ich habe hier und im englischen QNAP-Forum herumgestöbert und nach bestem Gewissen manche der vorgeschlagenen Empfehlungen umgesetzt.

Soweit ich es per "mdadm --detail" erkennen kann, ist das RAID erstmal in Ordnung und alle Superblöcke intakt (ich wundere mich nur über die Numerierung der Platten, aber das soll wohl nicht ungewöhnlich sein. )

[~] # mdadm --detail /dev/md1        Version : 1.0  Creation Time : Thu Dec 31 01:56:55 2015     Raid Level : raid5     Array Size : 5840623232 (5570.05 GiB 5980.80 GB)  Used Dev Size : 2920311616 (2785.03 GiB 2990.40 GB)   Raid Devices : 3  Total Devices : 3    Persistence : Superblock is persistent    Update Time : Tue Jan  5 19:23:37 2016          State : clean Active Devices : 3Working Devices : 3 Failed Devices : 0  Spare Devices : 0         Layout : left-symmetric     Chunk Size : 64K           Name : 1           UUID : 553fe61b:9f23ed34:d2d6c2d4:9b2a59cf         Events : 10759    Number   Major   Minor   RaidDevice State       0       8        3        0      active sync   /dev/sda3       2       8       19        1      active sync   /dev/sdb3       3       8       35        2      active sync   /dev/sdc3

Bei den Ausgaben zu "mdadm --examnie --scan" frage ich mich, wieso ich neben meinem Array (dev/md1) noch 4 weitere habe?

[/] # mdadm --examine --scanARRAY /dev/md/9  metadata=1.0 UUID=1d197c48:dc3c033c:1debfa77:443adead name=ARRAY /dev/md/256  metadata=1.0 UUID=8cb7532c:8e9735de:f7a282cf:fab35454 name=256   spares=1ARRAY /dev/md/1  metadata=1.0 UUID=553fe61b:9f23ed34:d2d6c2d4:9b2a59cf name=1ARRAY /dev/md/13  metadata=1.0 UUID=528a7738:dacec9e7:f2dad263:3a603c05 name=13ARRAY /dev/md/321  metadata=1.0 UUID=115ebc49:8e384871:5deff3d6:22746d35 name=321

Ich habe dann den Empfehlungen im Forum und der QNAP-FAQ folgend versucht, das Array aufzubauen. Hierfür habe ich alle Dienste gestoppt und über "mdadm -A /dev/md1 dev/sd[a-c]3" das Array zu assemblen versucht. Leider ohne Erfolg, da die Disks "busy" sind.

[/] # mdadm -A /dev/md1 /dev/sd[a-c]3mdadm: /dev/sda3 is busy - skippingmdadm: /dev/sdb3 is busy - skippingmdadm: /dev/sdc3 is busy - skipping

Ein manuelles Stoppen des Arrays funktionierte leider auch nicht, da irgrndein Prozess noch Zugriff hat (obwohl alle Services beendet wurden)

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

An dieser Stelle hänge ich nun und versuche herauszufinden, wieso sich erstens das Array nicht stoppen lässt und zweitens (und viel wichtiger) wie ich das Array wieder ans Laufen bekomme. Ich bin wieder für alle Vorschläge offen und dankbar.

Hallo dr_mike und danke für die Antwort,

"cat /proc/partitions" gibt mir folgendes wieder:

[/] # cat /proc/partitionsmajor minor  #blocks  name   8        0 2930266584 sda   8        1     530125 sda1   8        2     530142 sda2   8        3 2920311763 sda3   8        4     530144 sda4   8        5    8353796 sda5   8       32 2930266584 sdc   8       33     530125 sdc1   8       34     530142 sdc2   8       35 2920311763 sdc3   8       36     530144 sdc4   8       37    8353796 sdc5   8       16 2930266584 sdb   8       17     530125 sdb1   8       18     530142 sdb2   8       19 2920311763 sdb3   8       20     530144 sdb4   8       21    8353796 sdb5  31        0        640 mtdblock0  31        1        384 mtdblock1  31        2      32768 mtdblock2  31        3     221184 mtdblock3  31        4      32768 mtdblock4  31        5     221184 mtdblock5  31        6      15360 mtdblock6   9        9     530048 md9   9       13     458880 md13   9      256     530112 md256   9        1 5840623232 md1 253        1 2899337216 dm-1 253        0 2899337216 dm-0

Deine Vermutung bzgl. des laufenden Volumemanager LVM2 traf auch zu.

[/]# pvs  PV         VG   Fmt  Attr PSize PFree  /dev/md1   vg1  lvm2 a--  5.44t 2.68t

Heißt dies nun, dass der laufende Volumenmanager der Grund ist, dass der Check des Filesystems bisher weder über die Weboberfläche (siehe Post Nr. 1) noch über die Shell geklappt hat?

[/] # e2fsck -v -f /dev/md1
e2fsck 1.42.6 (21-Sep-2012)
/dev/md1 is in use.
e2fsck: Cannot continue, aborting.

Welche Möglichkeit gibt es nun, die Integrität des Dateisystems zu überprüfen und ggf. zu korrigieren? Kann ich bspw. einfach den Volumenmanager deaktivieren, um das Dateisystem zu überprüfen? Oder ist dies eine gänzlich alberne Idee?

Herzlichen Dank und Grüße

Hallo und wieder danke für Deine Antwort,

der Check des Volumes lief tatsächlich durch und gab mir folgende nächste Aufgabe

[/] # e2fsck -v -f /dev/mapper/cachedev1
e2fsck 1.42.6 (21-Sep-2012)
The filesystem size (according to the superblock) is 986873856 blocks
The physical size of the device is 724834304 blocks
Either the superblock or the partition table is likely to be corrupt!

Interpretiere ich den Output richtig, dass die eingestellte Größe des Dateisystems und die tatsächliche Größe nicht übereinstimmen? Kann man die korrekte Größe ermitteln und dann diese in die Partitionstabelle eintragen?

Lieben Dank und Grüße