ich bin mir jetzt nicht sicher, ob ich ein Hard- oder Softwareproblem habe. Falls dieser Thread in der falschen Kategorie hängt, bitte einfach umziehen.
Zu diesem Problem habe ich auch schon in einem anderen Forum versucht, Unterstützung zu bekommen, das war aber bisher erfolglos. Falls jemand diesen Thread verfolgen möchte, der wird hier fündig:
https://serversupportforum.de/threads/s ... ost-402986
Zum Problem:
Seit einigen Tagen beobachte ich, daß inaktive Festplatten unerwartet aus dem Schlafmodus geholt werden. Ich habe zwei ältere HDDs als Datenfriedhof an einem zusätzlichen SATA-Controller (Marvell 88se9215 Chipsatz) im PCIe-Steckplatz hängen. Diese sind nicht permanent im System eingebunden, sondern werden nur für die Sicherungen der Daten auf den SSDs aktiviert. Damit mehr Ruhe herrscht und nicht unnötig Energie verbraucht wird, schalte ich diese Platten regelmäßig nach Gebrauch mit hdparm -Y /dev/sd[e-f] oder automatisch ab.
Im syslog kann ich immer solche Aufzeichnungen zum Zeitpunkt des Aufweckens finden:
Code: Alles auswählen
2024-03-26T06:35:01.787287+01:00 HomeServer CRON[327616]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)
2024-03-26T06:36:33.720952+01:00 HomeServer kernel: [43588.471096] ata6.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
2024-03-26T06:36:33.720988+01:00 HomeServer kernel: [43588.471112] ata6.00: waking up from sleep
2024-03-26T06:36:33.720990+01:00 HomeServer kernel: [43588.471120] ata6: hard resetting link
2024-03-26T06:36:34.200620+01:00 HomeServer kernel: [43588.950935] ata6: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
2024-03-26T06:36:37.164573+01:00 HomeServer kernel: [43591.917313] ata6.00: configured for UDMA/133
2024-03-26T06:36:37.164600+01:00 HomeServer kernel: [43591.917331] ata6.00: retrying FLUSH 0xea Emask 0x0
2024-03-26T06:36:37.164602+01:00 HomeServer kernel: [43591.917492] ata6: EH complete
2024-03-26T06:36:37.416586+01:00 HomeServer kernel: [43592.167002] ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
2024-03-26T06:36:37.416613+01:00 HomeServer kernel: [43592.167019] ata5.00: waking up from sleep
2024-03-26T06:36:37.416615+01:00 HomeServer kernel: [43592.167027] ata5: hard resetting link
2024-03-26T06:36:37.892625+01:00 HomeServer kernel: [43592.642965] ata5: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
2024-03-26T06:36:37.904587+01:00 HomeServer kernel: [43592.655940] ata5.00: configured for UDMA/133
2024-03-26T06:36:37.904614+01:00 HomeServer kernel: [43592.655956] ata5.00: retrying FLUSH 0xea Emask 0x0
2024-03-26T06:36:37.904615+01:00 HomeServer kernel: [43592.656099] ata5: EH complete
Maßnahmen zur Fehlereingrenzung:
Ich hatte diese beiden Platten auch schon am internen OnBoard-SATA-Port hängen, dort wurden sie nicht regelmäßig aus dem Schlaf gerissen. Ich möchte jedoch am OnBoard-SATA-Controller aus Performance-Gründen das SSD-Setup behalten. Eine andere HDD, die ich testweise am externen Controller hängen hatte, blieb auch dort im Schlafmodus bis zum beabsichtigten Zugriff.
Ich frage mich nun, was die Ursache ist. Die beiden HDDs sind völlig unterschiedlich, eine 2.5" von Hitachi und eine 3.5" von Samsung. Die Test-HDD, die sowohl am OnBoard-Controller, als auch am PCIe-SATA-Controller problemlos schläft, ist eine 3.5" von Seagate.
Die o. a. Fehlermeldung entsteht auch nur beim Schlafmodus der beiden Platten. Ansonsten gibt's laut syslog oder dmesg keine Probleme mit diesen, wenn der cronjob läuft.
Laut https://linux-hardware.org/index.php?id ... -1b4b-9215 gibt es mit aktuellem Kernel keine Auffälligkeiten in Bezug auf den Chipsatz des Controllers.
Folgende Fragen hätte ich zu dem Thema:
- Kann mir jemand erklären, was diese Fehlermeldung im syslog technisch bedeutet? Ich bin nicht so tief in Hardwarethemen drin, um das interpretieren zu können.
- Inwieweit ist der sysstat Daemon überlebenswichtig für den Systembetrieb? Kann man dem beibringen, daß er die Finger von diesem oder jenem Laufwerk lassen soll – so wie man das z. B. auch dem smartd beibringen kann?
- Hat von Euch jemand eine Idee, wonach ich suchen könnte, um das Problem in den Griff zu bekommen?
Achim