Disco SATA com defeito, mas com erro periódico?

Disco SATA com defeito, mas com erro periódico?

Eu tenho um disco Seagate St2000dm001 2TB Barracuda Sata3 que está produzindo erros semelhantes a este:

[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

Testei o disco com cabos e máquinas diferentes e os erros persistem. Parece um caso claro de um disco quebrado, mas há uma diferença. Greping os erros ao fazer um muito longo mkfs.ext4 -c -cfornece um padrão periódico para os erros:

[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

É quase exatamente a cada 1 hora e 7 minutos. Achei que poderia estar relacionado a smartd, mas smartdnão estava funcionando. Então, estou preso: que tipo de falha de hardware daria um erro periódico com período de 1 hora e 7 minutos? Qualquer idéia seria muito apreciada.

Atenciosamente,

Nicolau

Responder1

São quase exatamente 4.000 segundos, dentro da precisão de um oscilador barato.

Isso significa que provavelmente algo no firmware da unidade SATA ou do controlador SATA faz isso automaticamente.

A razão para isso pode ser qualquer coisa, basicamente. Por exemplo, o firmware da unidade é redefinido a cada 4.000 segundos quando alguma sub-rotina de verificação de componente falha. O firmware do controlador SATA é redefinido a cada 4000 quando tenta renegociar um link e falha, ou qualquer outra coisa, na verdade (esses dois exemplos não são mais prováveis ​​do que qualquer outra coisa).

A única coisa que o tempo sugere é que o software decide fazer isso, seja um software executado como sistema operacional, como controlador ou como firmware de unidade. E isso pode ser um bug de software ou uma detecção real de um erro de hardware.

Então, é muito difícil diagnosticar isso. Se o controlador e a unidade já estiverem com as revisões de firmware recentes ( fwupdmgr get-updatesé seu amigo, para ambos), tudo bem.

informação relacionada