Fehlerhafte SATA-Festplatte, aber mit periodischem Fehler?

Fehlerhafte SATA-Festplatte, aber mit periodischem Fehler?

Ich habe eine Seagate St2000dm001 2TB Barracuda Sata3-Festplatte, die ähnliche Fehler erzeugt:

[Tue Jun 14 10:02:06 2022] ata2.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x6 frozen
[Tue Jun 14 10:02:06 2022] ata2.00: failed command: WRITE FPDMA QUEUED
[Tue Jun 14 10:02:06 2022] ata2.00: cmd 61/00:00:00:48:9f/02:00:b2:00:00/40 tag 0 ncq 262144 out
[Tue Jun 14 10:02:06 2022]          res 40/00:01:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
[Tue Jun 14 10:02:06 2022] ata2.00: status: { DRDY }
[Tue Jun 14 10:02:06 2022] ata2: hard resetting link
[Tue Jun 14 10:02:16 2022] ata2: softreset failed (1st FIS failed)
[Tue Jun 14 10:02:16 2022] ata2: hard resetting link
[Tue Jun 14 10:02:26 2022] ata2: softreset failed (1st FIS failed)
[Tue Jun 14 10:02:26 2022] ata2: hard resetting link
[Tue Jun 14 10:02:42 2022] ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[Tue Jun 14 10:02:42 2022] ata2.00: configured for UDMA/133
[Tue Jun 14 10:02:42 2022] ata2.00: device reported invalid CHS sector 0
[Tue Jun 14 10:02:42 2022] ata2: EH complete

Ich habe die Festplatte mit verschiedenen Kabeln und auf verschiedenen Rechnern getestet, und die Fehler bestehen weiterhin. Es scheint ein klarer Fall einer defekten Festplatte zu sein, aber es gibt einen Haken. Wenn man die Fehler während eines sehr langen Tests grept mkfs.ext4 -c -c, erhält man ein periodisches Muster für die Fehler:

[Mon Jun 13 10:47:02 2022] ata2.00: failed command: WRITE FPDMA QUEUED
[Mon Jun 13 11:51:08 2022] ata2.00: failed command: WRITE FPDMA QUEUED
[Mon Jun 13 12:55:14 2022] ata2.00: failed command: WRITE FPDMA QUEUED
[Mon Jun 13 14:01:21 2022] ata2.00: failed command: READ FPDMA QUEUED
[Mon Jun 13 15:08:27 2022] ata2.00: failed command: READ FPDMA QUEUED
[Mon Jun 13 16:15:33 2022] ata2.00: failed command: READ FPDMA QUEUED
[Mon Jun 13 17:22:39 2022] ata2.00: failed command: WRITE FPDMA QUEUED
[Mon Jun 13 18:29:43 2022] ata2.00: failed command: WRITE FPDMA QUEUED
[Mon Jun 13 19:36:49 2022] ata2.00: failed command: WRITE FPDMA QUEUED
[Mon Jun 13 20:43:55 2022] ata2.00: failed command: WRITE FPDMA QUEUED
[Mon Jun 13 21:50:02 2022] ata2.00: failed command: READ FPDMA QUEUED
[Mon Jun 13 22:57:08 2022] ata2.00: failed command: READ FPDMA QUEUED
[Tue Jun 14 00:04:14 2022] ata2.00: failed command: READ FPDMA QUEUED
[Tue Jun 14 01:11:17 2022] ata2.00: failed command: WRITE FPDMA QUEUED
[Tue Jun 14 02:15:24 2022] ata2.00: failed command: WRITE FPDMA QUEUED
[Tue Jun 14 03:19:30 2022] ata2.00: failed command: WRITE FPDMA QUEUED
[Tue Jun 14 04:26:36 2022] ata2.00: failed command: READ FPDMA QUEUED
[Tue Jun 14 05:33:42 2022] ata2.00: failed command: READ FPDMA QUEUED
[Tue Jun 14 06:40:48 2022] ata2.00: failed command: READ FPDMA QUEUED
[Tue Jun 14 07:47:54 2022] ata2.00: failed command: WRITE FPDMA QUEUED
[Tue Jun 14 08:55:00 2022] ata2.00: failed command: WRITE FPDMA QUEUED
[Tue Jun 14 10:02:06 2022] ata2.00: failed command: WRITE FPDMA QUEUED

Es passiert fast genau alle 1 Stunde und 7 Minuten. Ich dachte, es könnte damit zusammenhängen smartd, aber smartdes lief nicht. Ich stecke also fest: Welche Art von Hardwarefehler würde einen periodischen Fehler mit einer Periode von 1 Stunde und 7 Minuten verursachen? Ich wäre für jede Idee sehr dankbar.

Beste grüße,

Nikolaus

Antwort1

Das sind fast genau 4000 Sekunden und liegen damit im Bereich der Genauigkeit eines billigen Oszillators.

Dies bedeutet, dass dies wahrscheinlich automatisch durch etwas in der Firmware des SATA-Laufwerks oder des SATA-Controllers erfolgt.

Der Grund dafür kann grundsätzlich alles Mögliche sein. Beispielsweise kann die Firmware des Laufwerks alle 4000 Sekunden zurückgesetzt werden, wenn eine Subroutine zur Komponentenprüfung fehlschlägt. Die Firmware des SATA-Controllers kann alle 4000 Sekunden zurückgesetzt werden, wenn versucht wird, eine Verbindung neu auszuhandeln und dies fehlschlägt, oder eigentlich alles andere (diese beiden Beispiele sind nicht wahrscheinlicher als alles andere).

Das einzige, was der Zeitpunkt vermuten lässt, ist, dass die Software dies tut, egal ob es sich um Software handelt, die Sie als Betriebssystem, als Controller oder als Laufwerksfirmware ausführen. Und das könnte ein Softwarefehler oder die tatsächliche Erkennung eines Hardwarefehlers sein.

Das ist also wirklich schwer zu diagnostizieren. Wenn Controller und Laufwerk bereits die neuesten Firmware-Revisionen haben (das fwupdmgr get-updatesist für beide Ihr Freund), dann gut.

verwandte Informationen