125

Почему жесткий диск, который, как известно, имеет плохие блоки (проверено в HDTune и HDDScan), зависает всю мою систему?

Это не диск ОС; он подключен к другому порту SATA, и я пытаюсь скопировать файлы с него на другой исправный диск.

Я сталкивался с этой проблемой почти на каждом поврежденном жестком диске и на каждом ПК с Windows.

Я ожидал бы зависания только для программы, которую я использую для копирования файлов (Проводник Windows и т.д.), Но вместо этого весь мой компьютер дергается, и я не могу просматривать веб-страницы или смотреть фильмы, копируя файлы с поврежденного диска.

Длинная история.

Я живу в сельской местности, где есть проблемы с электричеством (отключение и т.д.). Я сам использую ИБП, и мои собственные жесткие диски в порядке. Но мои соседи часто просят помощи в решении проблем с их ПК, и я часто обнаруживаю, что их жесткие диски повреждены, скорее всего, из-за проблем с электричеством. Конечно, после замены поврежденного диска я предлагаю соседям купить ИБП.

Я всегда задавался вопросом, почему мой компьютер полностью зависает при получении данных с поврежденных дисков. Это аппаратная проблема? Это вызвано тем, как ОС читает данные? Это что-то специфичное для Windows, и я не буду испытывать это на * nix?

В любом случае, теперь я буду использовать некое специальное программное обеспечение (например, Unstoppable Copier от Roadkil) вместо Windows Explorer, хотя я не уверен, будет ли это работать по-другому, без замораживания всего ПК.

Это не просьба о помощи, а скорее в образовательных целях, поэтому я знаю, почему все так работает.

4 ответа4

166

Это одна из тех областей, где SATA неоптимален. Проблема заключается в уровне протокола межсоединения устройства хранения и, следовательно, не связана с тем, какое программное обеспечение вы используете. Использование другого копировщика файлов или другой операционной системы не может волшебным образом улучшить ситуацию, за исключением того, что он может попытаться установить различные значения времени ожидания, чтобы уменьшить влияние проблемы (что может или не может быть возможным в зависимости от аппаратного и микропрограммного обеспечения; см. Ниже). ).

Здесь есть несколько важных моментов:

  1. С SATA, если диск перестает отвечать на запросы, это может связать всю систему хранения, а не только один диск, который имеет проблемы. Он, безусловно, может связать весь контроллер, и, поскольку большинство потребительских систем имеют только один дисковый контроллер (встроенный в материнскую плату), это означает, что все хранилища. Еще хуже, если диск выйдет из строя нестандартным и / или непредвиденным образом, что может произойти, если диск будет маргинальным. Вы можете быть заинтересованы в том, как один диск в аппаратном массиве SATA RAID-10 может привести к полной остановке всего массива? Ошибка сервера.
  2. Большинство потребительских дисков SATA имеют длительные периоды ожидания по умолчанию (порядка минут), а многие потребительские диски SATA не имеют настраиваемого контроля исправления ошибок. Так называемые NAS-накопители часто имеют настраиваемую ERC, а высокопроизводительные - практически всегда; такие диски также могут иметь более короткие тайм-ауты по умолчанию (7 секунд - это обычное значение). Длительные периоды ожидания выгодны, если на диске хранится единственная копия данных, что, к сожалению, является обычным явлением в потребительских системах; они являются недостатком в конфигурации с резервированием или в тех случаях, когда вы просто хотите извлечь как можно больше из накопителя, прежде чем он еще больше испортится.
  3. Накопитель будет пытаться прочитать поврежденный сектор до тех пор, пока не достигнет своего порога тайм-аута или пока хост не сообщит об отмене. Поскольку шину SATA можно связать с ожиданием завершения чтения, ОС может не дать сигнал об отмене команды на уровне хранилища, а в крайних случаях диски могут даже не очень хорошо реагировать на сброс шины SATA. в такой ситуации.

Пункт № 1 является одним из основных пунктов продажи SAS на серверах; SAS имеет значительно лучшую обработку ошибок, чем SATA. Пункт № 2 является ограничением встроенного программного обеспечения накопителя, а № 3 действительно становится проблемой только из-за № 2.

Так что получается, что ОС выдает команду "чтение секторов" на диск, и отдельные сектора каким-то образом повреждены. Таким образом, диск переходит в режим повторных попыток, чтобы попытаться извлечь данные с пластин, снова и снова пытаясь считать, пока не получит достаточно хороших данных, чтобы исправление ошибок диска (FEC) могло исправить оставшиеся ошибки. Если вам не повезло, это может быть никогда, но накопитель будет пытаться работать довольно долго, прежде чем решит, что это чтение не будет успешным.

Поскольку операционная система ожидает чтения, это как минимум замедлит процесс копирования до обхода, и в зависимости от конкретной архитектуры ОС может вызвать прерывистость ОС или даже зависание на время. Диск на данный момент занят исходным чтением и не будет отвечать на дальнейшие команды чтения, пока не завершится та, которая выполняется в данный момент (успешно или неудачно), а другое программное обеспечение, как правило, не будет работать лучше, чем его операционная система. работает на.

Следовательно, все, что вызывает чтение в другом месте (в идеале, только на поврежденном диске), будет вынуждено ждать в очереди, пока поврежденный диск либо не успешно прочитает рассматриваемый сектор, либо решит, что его нельзя прочитать. Из-за неоптимальной обработки SATA дисками, не отвечающими на запросы, это может означать, что не только диск, с которого вы копируете, будет задерживать свой ввод / вывод. Это может очень легко заставить другое программное обеспечение работать медленно или не отвечать, так как это программное обеспечение ожидает завершения другого запроса ввода-вывода, даже если операционная система способна справиться.

Здесь также важно отметить, что дисковый ввод-вывод может происходить, даже если вы явно не обращаетесь к каким-либо файлам на диске. Двумя основными причинами этого могут быть исполняемый код загрузки по требованию и своп. Поскольку подкачка иногда используется, даже когда система не находится под давлением памяти, а исполняемый код загрузки по требованию распространен в современных системах и в современных форматах исполняемых файлов, непреднамеренная активность чтения с диска во время обычного использования является вполне реальной возможностью.

Как указано в комментарии к вопросу Matteo Italia, одной из смягчающих стратегий является использование другого межсоединения хранилища, что является сложным способом сказать «поместите диск в USB-корпус». Абстрагируясь от протокола USB запоминающего устройства, это изолирует проблемную часть SATA от остальной части вашей системы, что означает, что теоретически только проблемы ввода-вывода на этом диске должны затрагивать только ввод-вывод на этом конкретном диске.

В некотором смысле, именно поэтому SATA (в частности, SATA без ERC на уровне диска) часто не рекомендуется использовать для RAID (особенно для уровней RAID с избыточностью, которые среди стандартных являются всеми, кроме RAID 0); длительные периоды ожидания и плохая обработка ошибок могут легко привести к выбрасыванию целого устройства из массива для одного поврежденного сектора, с которым RAID-контроллер мог бы справиться очень хорошо, если существует избыточность, и контроллер хранилища просто знает, что это проблема. SAS был спроектирован для больших массивов хранения, и, таким образом, ожидалось, что время от времени будут возникать проблемы на различных дисках, что привело к тому, что он был разработан для изящной обработки в случае одного проблемного диска или запроса ввода-вывода, даже если диск не ' т. Проблемные диски не очень распространены в потребительских системах просто потому, что на них обычно не установлено много дисков, а на тех, которые установлены практически, никогда нет избыточности; Так как SATA нацелена на замену PATA/IDE, а не SCSI (последняя является нишей, на которую ориентирована SAS), вполне вероятно, что ее функции и требования по обработке ошибок (или гарантии) были сочтены адекватными для предполагаемого варианта использования.

3

Как было сказано выше, проблема с зависанием системы из-за плохого жесткого диска в первую очередь связана с длительными попытками диска восстановить нечитаемые данные из поврежденных секторов. Одним из преимуществ корпоративных дисков является очень короткий тайм-аут чтения для неисправных секторов. Использование корпоративного диска может до некоторой степени смягчить ваши проблемы, но не решит их.

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

2

Почему поврежденные жесткие диски замораживают всю систему?

Они не должны (в общем). Это действительно зависит от конкретной файловой системы, как происходит сбой диска.

Рассмотрим ZFS, которая разработана с нуля, чтобы иметь дело с некоторой отказоустойчивостью. Вот демонстрационное видео (и еще одно с более подробным объяснением), где они размещают ходовые диски на наковальне, качаются с помощью кувалды и просверливают другой диск. Все пока ZFS продолжает работать.

-2

Я думаю, что проблема, с которой вы сталкиваетесь, заключается в том, что низкоуровневая часть ОС много раз пытается прочитать плохие блоки перед тем, как сдаться. Эта процедура реализуется на низком уровне в случае, если она необходима во время загрузки или другой автономной операции, и, следовательно, ее трудно повторно ввести. Во время нормальной работы операционная система будет постоянно отображать страницы, и трудно дать приоритет конкурирующим запросам, потому что низкоуровневая система не будет знать приоритет процесса, которому принадлежит запрос пейджинга.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .