У меня есть два жестких диска, настроенных как массив RAID 1 на моем сервере (Linux, программный RAID с использованием mdadm), и один из них только что получил этот «подарок» в системном журнале:
Nov 23 02:05:29 h2 kernel: [7305215.338153] ata1.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x0
Nov 23 02:05:29 h2 kernel: [7305215.338178] ata1.00: irq_stat 0x40000008
Nov 23 02:05:29 h2 kernel: [7305215.338197] ata1.00: failed command: READ FPDMA QUEUED
Nov 23 02:05:29 h2 kernel: [7305215.338220] ata1.00: cmd 60/08:00:d8:df:da/00:00:3a:00:00/40 tag 0 ncq 4096 in
Nov 23 02:05:29 h2 kernel: [7305215.338221] res 41/40:08:d8:df:da/00:00:3a:00:00/00 Emask 0x409 (media error) <F>
Nov 23 02:05:29 h2 kernel: [7305215.338287] ata1.00: status: { DRDY ERR }
Nov 23 02:05:29 h2 kernel: [7305215.338305] ata1.00: error: { UNC }
Nov 23 02:05:29 h2 kernel: [7305215.358901] ata1.00: configured for UDMA/133
Nov 23 02:05:32 h2 kernel: [7305218.269054] ata1.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x0
Nov 23 02:05:32 h2 kernel: [7305218.269081] ata1.00: irq_stat 0x40000008
Nov 23 02:05:32 h2 kernel: [7305218.269101] ata1.00: failed command: READ FPDMA QUEUED
Nov 23 02:05:32 h2 kernel: [7305218.269125] ata1.00: cmd 60/08:00:d8:df:da/00:00:3a:00:00/40 tag 0 ncq 4096 in
Nov 23 02:05:32 h2 kernel: [7305218.269126] res 41/40:08:d8:df:da/00:00:3a:00:00/00 Emask 0x409 (media error) <F>
Nov 23 02:05:32 h2 kernel: [7305218.269196] ata1.00: status: { DRDY ERR }
Nov 23 02:05:32 h2 kernel: [7305218.269215] ata1.00: error: { UNC }
Nov 23 02:05:32 h2 kernel: [7305218.341565] ata1.00: configured for UDMA/133
Nov 23 02:05:35 h2 kernel: [7305221.193342] ata1.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x0
Nov 23 02:05:35 h2 kernel: [7305221.193368] ata1.00: irq_stat 0x40000008
Nov 23 02:05:35 h2 kernel: [7305221.193386] ata1.00: failed command: READ FPDMA QUEUED
Nov 23 02:05:35 h2 kernel: [7305221.193408] ata1.00: cmd 60/08:00:d8:df:da/00:00:3a:00:00/40 tag 0 ncq 4096 in
Nov 23 02:05:35 h2 kernel: [7305221.193409] res 41/40:08:d8:df:da/00:00:3a:00:00/00 Emask 0x409 (media error) <F>
Nov 23 02:05:35 h2 kernel: [7305221.193474] ata1.00: status: { DRDY ERR }
Nov 23 02:05:35 h2 kernel: [7305221.193491] ata1.00: error: { UNC }
Nov 23 02:05:35 h2 kernel: [7305221.388404] ata1.00: configured for UDMA/133
Nov 23 02:05:38 h2 kernel: [7305224.426316] ata1.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x0
Nov 23 02:05:38 h2 kernel: [7305224.426343] ata1.00: irq_stat 0x40000008
Nov 23 02:05:38 h2 kernel: [7305224.426363] ata1.00: failed command: READ FPDMA QUEUED
Nov 23 02:05:38 h2 kernel: [7305224.426387] ata1.00: cmd 60/08:00:d8:df:da/00:00:3a:00:00/40 tag 0 ncq 4096 in
Nov 23 02:05:38 h2 kernel: [7305224.426388] res 41/40:08:d8:df:da/00:00:3a:00:00/00 Emask 0x409 (media error) <F>
Nov 23 02:05:38 h2 kernel: [7305224.426459] ata1.00: status: { DRDY ERR }
Nov 23 02:05:38 h2 kernel: [7305224.426478] ata1.00: error: { UNC }
Nov 23 02:05:38 h2 kernel: [7305224.498133] ata1.00: configured for UDMA/133
Nov 23 02:05:41 h2 kernel: [7305227.400583] ata1.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x0
Nov 23 02:05:41 h2 kernel: [7305227.400608] ata1.00: irq_stat 0x40000008
Nov 23 02:05:41 h2 kernel: [7305227.400627] ata1.00: failed command: READ FPDMA QUEUED
Nov 23 02:05:41 h2 kernel: [7305227.400649] ata1.00: cmd 60/08:00:d8:df:da/00:00:3a:00:00/40 tag 0 ncq 4096 in
Nov 23 02:05:41 h2 kernel: [7305227.400650] res 41/40:08:d8:df:da/00:00:3a:00:00/00 Emask 0x409 (media error) <F>
Nov 23 02:05:41 h2 kernel: [7305227.400716] ata1.00: status: { DRDY ERR }
Nov 23 02:05:41 h2 kernel: [7305227.400734] ata1.00: error: { UNC }
Nov 23 02:05:41 h2 kernel: [7305227.472432] ata1.00: configured for UDMA/133
Из того, что я читал до сих пор, я не уверен, означают ли ошибки чтения, что у меня умирает жесткий диск (пока ошибок записи нет). У меня были ошибки жесткого диска в прошлом, и у них всегда были ошибки, связанные с невозможностью записи в определенные сектора журналов. Не в этот раз.
Стоит ли заменять диск? Может ли что-то еще быть причиной проблемы?
Я запланировал smartctl -t long тест, который закончится через пару часов. Надеюсь, это даст мне дополнительную информацию.
ОБНОВЛЕНИЕ: Произошло что-то вроде чуда. Подробности ниже:
Я делал резервные копии некоторых файлов с этой машины, готовясь заменить неисправный диск. Затем, когда я копировал эти огромные файлы, я получил это электронное письмо с проверкой журнала:
Security Events for kernel
=-=-=-=-=-=-=-=-=-=-=-=-=-
Nov 23 17:16:24 h2 kernel: [7359837.963597] end_request: I/O error, dev sdb, sector 1202093816
Nov 23 17:16:41 h2 kernel: [7359855.196334] end_request: I/O error, dev sdb, sector 1202093816
System Events
=-=-=-=-=-=-=
Nov 23 17:14:06 h2 kernel: [7359700.193114] ata2.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x0
Nov 23 17:14:06 h2 kernel: [7359700.193139] ata2.00: irq_stat 0x40000008
Nov 23 17:14:06 h2 kernel: [7359700.193158] ata2.00: failed command: READ FPDMA QUEUED
Nov 23 17:14:06 h2 kernel: [7359700.193180] ata2.00: cmd 60/08:00:58:03:aa/00:00:47:00:00/40 tag 0 ncq 4096 in
Nov 23 17:14:06 h2 kernel: [7359700.193181] res 41/40:08:58:03:aa/00:00:47:00:00/00 Emask 0x409 (media error) <F>
Nov 23 17:14:06 h2 kernel: [7359700.193247] ata2.00: status: { DRDY ERR }
Nov 23 17:14:06 h2 kernel: [7359700.193265] ata2.00: error: { UNC }
Nov 23 17:14:06 h2 kernel: [7359700.194458] ata2.00: configured for UDMA/133
Ой! Мои волосы, если они были на бритой голове, встали дыбом. Видите ли, это реально плохие сектора на второй водить машину. Что теперь? Что мне делать с двумя неисправными дисками?
Я подумал и решил, что я:
Поэтому я заменил второй, а не тот, о котором изначально задавал вопрос. У меня было несколько разделов, каждый из которых был настроен на отдельный RAID, и я надеялся, что смогу повторно синхронизировать хотя бы корневой и загрузочный, так что мне не придется переустанавливать все на сервере. Возможно, мне придется восстановить огромный раздел данных из резервной копии, но я бы сэкономил немного времени.
Заменил привод, запустил ресинхронизацию. Корневой и загрузочный разделы (около 50 ГБ) обновились очень быстро. Ошибок нет. Я счастливый турист!
Просто для удовольствия, давайте попробуем повторно синхронизировать огромный раздел данных - это около 2 ТБ с 500 ГБ данных на нем. Я запустил ресинхронизацию и некоторое время наблюдал за ней. Казалось, это займет целую вечность, и я подключил сервер к сети, позволив пользователям использовать свои данные. Повторная синхронизация происходит в фоновом режиме. И, что вы знаете, примерно через 18 часов повторная синхронизация закончилась без ошибок. Сервер теперь полностью жив.
Интересно, стоит ли мне сейчас заменить оригинальный диск. Я уверен, что бог серверов жестких дисков надо мной смеется.
Он не собирается умирать .. Он уже мертв.
Замените его как можно скорее и восстановите из резервных копий, если вы потеряете какие-либо данные.
Не могу найти надежного источника для подтверждения моего собственного мнения, но я действительно думаю, что это это не повреждение оборудования. Это скорее проблема поиска данных.
Если какие-либо данные записываются на диск в том же месте, где произошла ошибка операции чтения, они должны быть доступны для чтения.
Итак, в заключение, ваши текущие данные может быть невозможно восстановить на этом диске, но поскольку у вас есть RAID-массив, вы все равно можете вернуть свои данные с другого диска и сделайте резервную копию, затем отформатируйте неисправный диск и повторно синхронизируйте массив RAID.
Эта проблема может возникнуть из-за электромагнитных полей, изменяющих содержимое жесткого диска.