Datenträger deaktiviert Inhalt wird emuliert


MPC561

Recommended Posts

Hallo,

 

Ich habe Unraid seit Weihnachten auf einem ATOM Board mit zusätzlichem Sata Marvell 88SE9215 Controller.

1x Cache, 1x Parity und 5 Datenplatten im Array.

Bis dato lief alles hervorragend. Apps, Dockerimages etc.

 

 

Heute habe ich auf 6.9.2 geupdated und seitdem wird mir für Datenträger 5 die Fehlermeldung "Datenträger deaktiviert, Inhalt wird emuliert" angezeigt.

 

Interessanterweise meldet mir ein smarttest via WebGui keine Fehler. Was mich, vielleicht fehlerhaft, darauf schliessen lässt das alles in Ordnung sein sollte.

 

Bevor ich den Server aus seiner dunklen Ecke hole und aufschraube umd die Platte in einem anderen rechner zu checken. Gibt es onBoardmittel via Terminal mit denen ich noch irgendwas checken kann?

 

Und allgemein, ist die Platte defekt oder hab ich rigendwas nur nicht aktiviert, was auch immer?

 238124264_Bildschirmfoto2021-04-11um13_34_49.thumb.png.c1955de9473da38a5deff1f8b69c1e28.png

Bildschirmfoto 2021-04-11 um 13.35.56.png

Bildschirmfoto 2021-04-11 um 13.36.30.png

Bildschirmfoto 2021-04-11 um 13.36.35.png

Link to comment

Ich hatte den Server als erstes nach dem Fehler rebootet. Hätte ich wohl nicht machen sollen. Die aktuellen logs (wenn ich an der richtigen Stelle schaue) sind für mich unauffällig.

Oder gibts da noch einen Tip wo ich noch schauen könnte?

 

Interessanterweise ist es die neueste der Platten und keine die am Marvell SATA Controler hängt. (Ich dachte erst der macht Ärger)

 

Nun ich habe wie im Wiki empfohlen den Server runterfahren, Platte abgestöpselt. Server hochgefahren und Array gestartet, dann gestoppt, Server wieder runtergefahren, Platte angestöpselt, Server gestartet, Array gestartet und jetzt läuft das Rekonstruieren.

 

Wie gesagt wenns noch Tips gibt würde ich mich darüber freuen.

 

Gruss,

MPC561

Link to comment

Das hätte ich nicht gemacht. Du hast du keine Ahnung ob das der einzige Fehler war. Wenn es einen globaleren Fehler gibt, wird die Parität nun teilweise korrupte Daten wiederherstellen. Ich würde daher nach der Rekonstruktion die Daten einem Checksummen-Abgleich mit deinem Backup unterziehen.

 

Oder wann war dein letzter Parity Check?

 

Du darfst nie vergessen, dass die Rekonstruktion aus der Parität und all deinen Platten entsteht. Gab es dabei irgendwann mal Fehler, dann besteht immer die Gefahr, dass die Parität falsch ist.

 

Ich hätte eine neue Platte gekauft, auf der die Rekonstruktion gemacht und dann die vermeintlich defekte gemountet und abgeglichen. Schließlich ist die vermeintlich defekte ja nur rausgeworfen worden. Ihre Daten wären also noch vorhanden gewesen.

Link to comment

Der letzte Paritätscheck war vor ca. einer Woche. Seitdem ist nichts markantes geschrieben worden (Dockerimage Daten). 

 

Aber ja, ich habe auch den Verdacht das es irgendwo ein tieferliegendes Problem gibt. Der Rechner lief 4 Monate anstandslos durch. Dann hing er und ich musste hart rebooten. Und seitdem noch einmal, um genau zu sein vor einer Woche, danach lief auch der Paritätscheck. Da liess er sich aus dem S3 nicht mehr via WOL wecken. Der Druck auf den EIN/AUS Schalter weckte das System zwar aber ... keine Kommunikation, also wieder hart resetet.

 

 

Beim erneuten Auftreten. Was sollte ich tun? Bzw. welche Logs sichern?

 

Gruss,

MPC561

Link to comment

Interessant, genau das ist mir über Nacht auch passiert.
 

Ich habe, nachdem ich jetzt mit meinen Daten soweit von meiner alten NAS umgezogen bin die erste Platte der NAS in das Unraid reingehängt um noch etwas Puffer zu haben. Der Vorgang dauerte natürlich auch mit einer 3TB Platte etwas. Heut morgen war dann die 10 TB Datenplatte deaktiviert. Es standen 2 Fehler dran, welche ich jedoch nicht ausfindig machen konnte. Ich habe daraufhin unRAID rebootet, dies hat jedoch auch nur den Error Counter auf 0 zurück gesetzt. 

 

1497470153_Screenshot2021-04-12115428.thumb.png.e9b75018da4968dcdb6c4476826110cd.png

 

2067039811_Screenshot2021-04-12115514.png.7982d941f11a1c21f9815531bc6fee45.png

 

Auch während des Bootvorgangs gibt er im Log nicht an, warum er sie herausgenommen hat geschweige denn sie nicht wieder aufnimmt. 

Ich bin nur froh, das ich kurz zuvor schon die Parität hergestellt habe sonst wäre ich jetzt schon etwas bleich um die Nase rum, nachdem ich die Platten aus der alten NAS genommen habe. xD

 

Durch den Neustart sind jetzt natürlich auch bei mir die 2 Fehler weg.

Edited by marcoj1984
Link to comment
1 hour ago, marcoj1984 said:

Ich habe daraufhin unRAID rebootet

Bitte macht sowas nicht. Ihr habt entweder HDD Fehler oder temporäre Fehler mit eurer Verbindung zur HDD oder euer RAM ist kaputt. All das kann man in den Logs ablesen. Aber sobald ihr neu startet sind diese Logs weg. Wen man jetzt zB mit fehlerhaftem RAM einen Parity Rebuild macht, sind die Daten garantiert korrupt, egal ob man Ende "erfolgreich" da steht, denn der Vorgäng verlässt sich darauf, dass der RAM in Ordnung ist. Er prüft nicht während dem Parity Rebuild ob das was im RAM liegt auch richtig ist.

 

1 hour ago, marcoj1984 said:

Auch während des Bootvorgangs gibt er im Log nicht an

Fehler müssen nicht permanent auftreten und ganz sicher nicht nur beim Einbinden der HDD ins System. Da kann alles mögliche los sein.

 

1 hour ago, marcoj1984 said:

das ich kurz zuvor schon die Parität hergestellt habe sonst wäre ich jetzt schon etwas bleich um die Nase rum, nachdem ich die Platten aus der alten NAS genommen habe. xD

Backup Backup Backup!

Link to comment
2 minutes ago, mgutt said:

Bitte macht sowas nicht. Ihr habt entweder HDD Fehler oder temporäre Fehler mit eurer Verbindung zur HDD oder euer RAM ist kaputt. All das kann man in den Logs ablesen. Aber sobald ihr neu startet sind diese Logs weg. 

 

Ich bin davon ausgegangen das ich nach einem Reboot noch hinein schauen kann. 

Wie lässt man es denn richtig loggen? Logserver bringt da ja auch nichts, wenn er auf der selben Umgebung läuft.

 

2 minutes ago, mgutt said:

Fehler müssen nicht permanent auftreten und ganz sicher nicht nur beim Einbinden der HDD ins System. Da kann alles mögliche los sein.

 

Ich hätte hier gedacht, das er wenigstens beim Booten logt warum er die Platte zwar mountet aber nicht im Array aktiviert. 

 

6 minutes ago, mgutt said:

Backup Backup Backup!

 

Deswegen nur etwas blass... wäre halt mit Arbeit verbunden.

 

 

 

Also könnte man davon ausgehen, dass er die Platte ausgehängt hat weil er einen Fehler gefunden hat.

Da alle Docker + VMs im Cache laufen und ich eigentlich nur Dokumente/Bilder/Musik/Filme auf der Datenplatte habe, dass ich bis auf die Filme meine Daten lösche, das Array neu aufsetze und die Daten aus der Cloud neu ziehen lasse. Wenn irgendwann mal ein Film herumspinnt, kann ich ihn ja immer noch von der BD neu kopieren.

Aber kann ich das Array neu aufsetzen mit einer bestehenden Datenplatte? Sonnst müsste ich ja nochmal 7TB durch das Netz schieben, Parität aufbauen etc. 

Link to comment

Ich hab grad nochmal geschaut. Auch die 2 Mails die versendet wurden waren jetzt nicht sehr aufschlussreich:

 

 

Event: Unraid Disk 1 error
Subject: Alert [TOWER] - Disk 1 in error state (disk dsbl)
Description: ST10000VN0008-2PJ103_ZS503EBB (sdd)
Importance: alert

 

 

Event: Unraid array errors
Subject: Warning [TOWER] - array has errors
Description: Array has 1 disk with read errors
Importance: warning

Disk 1 - ST10000VN0008-2PJ103_ZS503EBB (sdd) (errors 2)

 

 

Vielleicht sollte man hier auch etwas mehr preisgeben wenn schon per Default die logs beim Neustart verschwinden.

Es hätte ja auch was mit der Stromversorgung sein können was es ausgelöst hat.

 

Da fällt mir direkt auf steht doch read errors drin xD

Edited by marcoj1984
Link to comment

Ok nun bin ich total verwirrt.

Ich befürchte ich sollte nochmal von vorn anfangen mit dem Array.
Aber zuvor muss ich irgendwie den Arbeitsspeicher testen um sicher zu gehen.

 

Nachdem er die 10 TB datenplatte deaktiviert hatte habe ich eine Prüfung angestoßen, welche soweit auch erfolgreich durchlief.

 

1013613230_Screenshot2021-04-13115044.thumb.png.5a6828845985b34a30ff7225874b0c29.png

 

Jetzt habe ich mir "den Spass" erlaubt die 10 TB Platte zu entfernen und wieder hinzuzufügen.

Daraufhin läuft nun ein Paritäts-Sync/Datenwiederherstellungs Prozess.

Dieser lief für gut 1,5h Stunden, als dann plötzlich Lesefehler auftraten.

Interessanterweise traten diese nicht wie beim Ursprung auf Disk 1 auf sondern direkt gleich bei Disk 0 und 2.

Und wenn man sich die Menge anschaut ist es auch extrem.

 

363330013_Screenshot2021-04-13115007.thumb.png.40c9c96ea440c85ab4720e5fbab3f93c.png

 

1851923722_Screenshot2021-04-13114710.png.1ccedd8078c6427e02677b76cf4d71c5.png

 

930118081_Screenshot2021-04-13121353.thumb.png.faefe79253ccd1420025cedd68d456a3.png

 

Da gestern nichts gefunden wurde und das System mit dem Array aktuell so ankommt, denke ich, dass ich um einen Neustart des Arrays nicht herum kommen werde.

Aber zuvor würde ich gern den Arbeitsspeicher Testen.

 

So wie die Lesefehler zwischen den Platten umherspringen gehe ich stark davon aus, dass wenn es ein Hardwarefehler ist, dieser dort zu finden sein dürfte.

Irgendwelche Ideen für eine zuverlässige RAM Prüfung?

 

 

 

 

Edited by marcoj1984
Link to comment
45 minutes ago, marcoj1984 said:

Irgendwelche Ideen für eine zuverlässige RAM Prüfung?

Ja, Memtest86.

Ist auch auf dem Unraid-Stick. Einfach beim hochfahren, wo das Auswahlfenster kommt von Unraid, Memtest86 auswählen.

Falls du mehrere RAM-Sticks hast, am besten einzeln testen.

Link to comment

So Problem gebannt. Der Arbeitsspeicher war es nicht, der Test lief Problemlos durch.
Bei mir lag es an dem onboard SATA III Marvell Controller. Ich hatte ohnehin das Problem, dass sobald ich 2 HDDs an dem hatte, im unRAID keine mehr auftauchte obwohl sie von Controller gelistet wurden. Hier im Forum hatte ich gelesen das es wohl ein Bug sei mit Marvel Controllern und Virtualisierung und man hier mit iommu=pt das ganze "umgehen" könnte. Dies hat soweit auch wunderbar geklappt.

 

Entweder hat der Controller einen an der Klatsche oder es ist nicht sinnvoll iommu=pt zu setzen. Zumal soweit ich das gesehen habe dies für AMD Systeme ist und nicht für Intel. Ich habe es jedenfalls erstmal so gelöst, dass ich einen anderen SATA II Controller vom Board anstelle des SATA III Marvels genommen habe. Für die Datenplatten ist SATA II ausreichend. Und siehe da, es läuft und es gibt keine Lesefehler mehr. Von meiner Seite sehe ich mein Problem damit als erledigt an.

 

Hatte also nichts mit dem Update zu tun. War nur ein ungünstiger Zeitpunkt bei mir. An dem alles aufeinander traf.

Bleibt nur noch die Frage was aus MCP561 seinem Problem geworden ist.

Edited by marcoj1984
Link to comment

Und wieder das Problem. Gestern hat ein FI Schalter ausgelöst und mein Server war down. Hochfahren -- alles ok. Resync/Paritätscheck hat sich gestartet. Lief bis 58% und dann wurde die Platte wieder disabled.

 

Noch habe ich nicht gebootet. Welche Logs soll ich jetzt speichern?

 

// Edit Ich habe jetzt mal selbst nachgeschaut und diesmal stehen viele Fehlermeldungen im Log.

 

Unraid Disk 5 error: 18-04-2021 04:07

Alert [HEKTOR] - Disk 5 in error state (disk dsbl)
HGST_HUS728T8TALE6L4_VDKU216M (sdg)

 

Die Logs starten aber erst um 04.36 Uhr. Und massig eintrage sind von der Cache Platte.sdh, während die die disabled wurde sdg ist.

 

Gruss,

MPC561

 

syslog.txt.zip

Edited by MPC561
Link to comment

Ich habe nochmal nachgedacht wo meine Probleme herkommen könnten.

 

- powertop --auto-tune

- Nutzung einer Pico-PSU (160W, Netzteil 120W)

- Marvell 88SE9215 Sata 4 Port controller

 

Ich habe auch nochmal einen extended Smart test mit der problematischen Datenplatte gemacht. Der ist mir zwei mal abgebrochen. Das zweite mal nachdem ich powertop schon deaktiviert hatte. Deswegen schliesse ich powertop "erstmal" aus. Ohne powertop ist das System allerdings reaktiver. Sprich, ich werde mich mit powertop später noch detaillierter beschäftigen und nur dedizierte Funktionen/Komponenten deaktivieren.

 

Deswegen lag mein Fokus dann auf dem Marvell 88SE9215. Mir war schon bewusst das der Probleme machen kann, ich habe den Thread hier im Forum vor meinen Kauf gelesen. Aber ich fand keinen anderen erschwinglichen 4 port SATA Controller nit PCIex1 (Die ASM Controller hatten alle nur 2 port). Auf den PCIex1 bin ich leider wegen meinem J4105 Mainboard limitiert.

 

Also habe ich einen neuen SATA Controller geordert und eingebaut. Das ist ein 4 port SATA controller bei dem bei keinen Verkäufer der Chipsatz dabei steht, nur eine SU-SA3004 V2. 

Nach langem suchen fand ich heraus das der zwei ASM1061/1062 nutzt. Darauf habe ich den geordert und eingebaut. 

 

Danach lief der extended smartctl test durch. Ich werde das jetzt weiter beobachten.

 

Gruss,

MPC561

 

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.