Неисправный диск SATA, но периодически возникают ошибки?

Неисправный диск SATA, но периодически возникают ошибки?

У меня есть диск Seagate St2000dm001 2 ТБ Barracuda Sata3, который выдает ошибки, похожие на эту:

[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

Я протестировал диск с разными кабелями и на разных машинах, и ошибки остались. Похоже на явный случай сломанного диска, но есть нюанс. Поиск ошибок при выполнении очень долгого mkfs.ext4 -c -c, дает периодическую картину ошибок:

[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

Это происходит почти точно каждые 1 час и 7 минут. Я думал, что это может быть связано с smartd, но smartdне было запущено. Итак, я застрял: какой тип аппаратной неисправности может давать периодическую ошибку с периодом 1 час и 7 минут? Любые идеи были бы весьма признательны.

С наилучшими пожеланиями,

Николас

решение1

Это почти ровно 4000 секунд, что соответствует точности дешевого осциллятора.

Это означает, что, вероятно, что-то в прошивке диска SATA или контроллера SATA делает это автоматически.

Причиной этого может быть что угодно, в принципе. Например, прошивка привода сбрасывается каждые 4000 с, когда некоторая подпрограмма проверки компонентов дает сбой. Прошивка контроллера SATA сбрасывается каждые 4000 с, когда она пытается повторно согласовать соединение и это дает сбой, или что-то еще, на самом деле (эти два примера не более вероятны, чем все остальное).

Единственное, что предполагает время, это то, что это программное обеспечение решает сделать это, будь то программное обеспечение, которое вы запускаете как операционную систему или как контроллер или как прошивку привода. И это может быть программной ошибкой или реальным обнаружением аппаратной ошибки.

Так что, действительно трудно диагностировать это. Если контроллер и привод уже имеют последние версии прошивки ( fwupdmgr get-updatesваш друг, для обоих), ну.

Связанный контент