Ralle

I tested it several times, if I unplug SATA and simulate a link down, unRAID tells me nothing in the web interface. Only temperatures are only displayed with a "*". Only when I then try read/write to one of the disconnected disks, then unRAID warns me.

No I mean the data disks. After a short time, they are marked as deactivated, but unRAID does not issue an alarm message, neither via the interface nor via mail. Only when you actively access it, a message comes.

If due to an error (loose cable, overvoltage, overheating) of the SATA controller the connection to the hard disk is lost, the log currently shows "SATA link down", but unfortunately unRAID does not report an error in the web interface. Maybe this error could be included so that the web interface (and the mail alert service) reacts accordingly.

Ja das werde ich auch machen 🙂

Geht leider auch nicht. Dann halt so, wie ich es eben auch probiert habe: unRAID läuft, Platten legen sich schlafen, beide SATA Kabel vom Board gezogen, wir tuen jetzt einfach mal so, als das der Controller sich in Rauch aufgelöst hat, egal ob der auf dem Board oder aber per Erweiterungskarte. Er ist quasi defekt und kann keine Verbindung mehr zu den Festplatten aufbauen. Dann habe ich die Platten aufgeweckt, alle Einträge bis zu 16:28:50 entstanden durch das manuelle Hochfahren der Festplatten. Zu dem Zeitpunkt keine Meldung in unRAID. Ab 16:36:36 hab ich dann direkt auf den freigegebenden SMB Ordner zugriffen, da kam dann auch die Meldung direkt in unRAID. Mar 23 16:27:47 Tower emhttpd: spinning down /dev/sdc Mar 23 16:27:48 Tower emhttpd: spinning down /dev/sdb Mar 23 16:28:27 Tower kernel: ata4: SATA link down (SStatus 0 SControl 300) Mar 23 16:28:33 Tower kernel: ata4: SATA link down (SStatus 0 SControl 300) Mar 23 16:28:38 Tower kernel: ata5: SATA link down (SStatus 0 SControl 300) Mar 23 16:28:43 Tower kernel: ata5: SATA link down (SStatus 0 SControl 300) Mar 23 16:28:49 Tower kernel: ata4: SATA link down (SStatus 0 SControl 300) Mar 23 16:28:49 Tower kernel: ata4.00: disabled Mar 23 16:28:49 Tower kernel: ata4.00: detaching (SCSI 4:0:0:0) Mar 23 16:28:49 Tower kernel: sd 4:0:0:0: [sdb] Synchronizing SCSI cache Mar 23 16:28:49 Tower kernel: sd 4:0:0:0: [sdb] Synchronize Cache(10) failed: Result: hostbyte=0x04 driverbyte=0x00 Mar 23 16:28:49 Tower kernel: sd 4:0:0:0: [sdb] Stopping disk Mar 23 16:28:49 Tower kernel: sd 4:0:0:0: [sdb] Start/Stop Unit failed: Result: hostbyte=0x04 driverbyte=0x00 Mar 23 16:28:49 Tower emhttpd: read SMART /dev/sdb Mar 23 16:28:49 Tower kernel: ata5: SATA link down (SStatus 0 SControl 300) Mar 23 16:28:49 Tower kernel: ata5.00: disabled Mar 23 16:28:49 Tower kernel: ata5.00: detaching (SCSI 5:0:0:0) Mar 23 16:28:49 Tower kernel: sd 5:0:0:0: [sdc] Synchronizing SCSI cache Mar 23 16:28:49 Tower kernel: sd 5:0:0:0: [sdc] Synchronize Cache(10) failed: Result: hostbyte=0x04 driverbyte=0x00 Mar 23 16:28:49 Tower kernel: sd 5:0:0:0: [sdc] Stopping disk Mar 23 16:28:49 Tower kernel: sd 5:0:0:0: [sdc] Start/Stop Unit failed: Result: hostbyte=0x04 driverbyte=0x00 Mar 23 16:28:50 Tower emhttpd: read SMART /dev/sdc Mar 23 16:36:36 Tower kernel: md: disk1 read error, sector=24 Mar 23 16:36:36 Tower kernel: md: disk0 read error, sector=24 Mar 23 16:36:36 Tower kernel: XFS (md1): metadata I/O error in "xfs_btree_read_buf_block.constprop.0+0x75/0xc1 [xfs]" at daddr 0x18 len 8 error 5 Mar 23 16:36:36 Tower kernel: XFS (md1): xfs_do_force_shutdown(0x1) called from line 296 of file fs/xfs/xfs_trans_buf.c. Return address = 00000000a527019e Mar 23 16:36:36 Tower kernel: XFS (md1): I/O Error Detected. Shutting down filesystem Mar 23 16:36:36 Tower kernel: XFS (md1): Please unmount the filesystem and rectify the problem(s)

Die Funktion hat mein BIOS leider nicht. Was ist wenn es den Controller betrifft? Wenn es den abschießt, ist die Verbindung ja eigentlich auch offen. Da das Logfile von damals ist, hab ich leider keinen Zugriff mehr auf das Log

ich habe heute mal das Worst Case Szenario ausprobiert: Parity + Disk 1 im standby, also mal von der Disk 1 das SATA Kabel entfernt. SMART Check hab ich vorher auf 1 Minute gesetzt. Nichts passiert, kein Nachrichten seitens unRAID (weder Weboberfläche noch Mail). Nach 30 Minuten kam immer noch nichts. Hab dann einfach mal auf einen Share unter Windows zugegriffen, nach 1-2 Sekunden hatte ich Zugriff und das Video wurde gestartet. Dann endlich kam in der Weboberfläche eine Meldung, zeitgleich auch eine Mail. Warum so verzögert? Nächster Test, selbe Situation wie oben, nur habe ich einfach die Platten manuell aus dem Standby geholt und wollte mal schauen, was unRAID damit anstellt. Nichts, keine Meldung, beide Platten werden als aktiv angezeigt, lediglich bei der Festplatte mit dem abgezogenem Kabel wurde die Temperatur mit einem "*" dargestellt. Weder über der Weboberfläche, noch per Meldung kam eine Mail. Oder noch schlimmer: Disk 1 fällt aus, ich greife erst nach 1 Woche auf das NAS mal wieder zu und in dem Zeitraum gab es nur noch die Parity Platte? Was ist wenn die in der Zeit auch noch ausgefallen wäre, zum Beispiel direkt nach dem Hochfahren aufgrund meines Zugriffes? Oder das der SATA Controller ausgestiegen ist und alle Platten nicht mehr verfügbar sind? Bin da ehrlich gesagt leicht schockiert, dass da unRAID so harmlos damit umgeht. Übersehe ich da irgendwas oder ist die Vorgehensweise seitens des OS so normal? Man hat zwar externe Backups vorliegen, aber dennoch schmeckt mir das nicht. Die System Notifications hatte ich aktiviert und eingerichtet. Zusätzlich lasse ich mir zum Testen jede Stunde eine Nachricht vom Status des Arrays schicken. Habe das Ganze also nochmal probiert: Platten im Standby, Disk 1: Daten abgezogen, Strom abgezogen. Das System anschließend 3h laufen lassen. In der Zeit kamen 2 Mails vom Status des Arrays an (hat sich zeitlich etwas überschnitten): Event: Unraid Status Subject: Notice [UNRAID] - array health report [PASS] Description: Array has 3 disks (including parity & cache) Importance: normal Parity - WDC_WD15EARS-00MVWB0_WD-WMAZA2497899 (sdb) - standby [OK] Disk 1 - WDC_WD15EZRX-00D8PB0_01KATHR-0CC (sdd) - standby [OK] Cache - CT120BX500SSD1_1930E1902C6A (sdc) - standby [OK] Wie gesagt, Disk 1 hatte zu dem Zeitpunkt weder Strom noch Daten, die kann nicht "OK" sein. Weder auf der Weboberfläche, noch per Mailalarm kam irgendwas rein. Da in der Zeit kein Zugriff auf die Platten erfolgt, hab ich an Disk 1 wieder Daten ran und Strom, anschließend per Netzwerk auf die Daten zugegriffen. Platten fuhren hoch und zack meldete unRAID "Disk 1 - disabled". Also hat das OS es sehrvoll mitbekommen, dass ich die Disk 1 entfernt hatte, fand es aber nicht interessant genug, das zu melden. Im Log stand nämlich zu dem Zeitpunkt des Abziehends auch folgendes: May 14 15:53:40 UNRAID kernel: ata4: SATA link down (SStatus 0 SControl 300) May 14 15:53:45 UNRAID kernel: ata4: SATA link down (SStatus 0 SControl 300) May 14 15:53:51 UNRAID kernel: ata4: SATA link down (SStatus 0 SControl 300) May 14 15:53:51 UNRAID kernel: ata4.00: disabled May 14 15:53:51 UNRAID kernel: ata4.00: detaching (SCSI 4:0:0:0) May 14 15:53:51 UNRAID kernel: sd 4:0:0:0: [sdd] Synchronizing SCSI cache May 14 15:53:51 UNRAID kernel: sd 4:0:0:0: [sdd] Synchronize Cache(10) failed: Result: hostbyte=0x04 driverbyte=0x00 May 14 15:53:51 UNRAID kernel: sd 4:0:0:0: [sdd] Stopping disk May 14 15:53:51 UNRAID kernel: sd 4:0:0:0: [sdd] Start/Stop Unit failed: Result: hostbyte=0x04 driverbyte=0x00 Hier sieht man eindeutig das unRAID mitbekommen hat das eine Platte fehlt, gemeldet wurde mir bis zum Hochfahren des Array's leider nichts. Mich würde einfach mal interessieren ob jemand sowas schon mal probiert hat oder aber sogar einen richtigen Festplattenausfall hatte. P.S.: Nicht wundern das der Beitrag fast identisch ist mit dem Beitrag aus einem anderem Forum, war damals mein Text den ich jetzt der einfacherheithalber einfach nur kopiert und noch etwas ergänzt habe. Gruß