Винчестер: WD5000 AAKS, новый, после проверки MHDD был "чистым". По независящим причинам (плохой блок питания), около месяца он работал в температурном режиме 50-60 градусов, я посмотрел SMART - в графе "Temperature" было значение 84.
Проблема: после проверки MHDD, найдено 8 UNC блоков, 1 блок ">500ms" и 3 ">150" ms.
Вопрос: насколько стоит использовать этот винчестер в дальнейшем, в плане надежности? Имеет смысл делать "erase waits" MHDD?
Erase делать стоит по тому как после него поймеш реальные это или софтовые бэды.
Но после таких температур скорей всего что реальные. Да и выложи весь СМАРТ винта.
andponomarev насколько стоит использовать этот винчестер в дальнейшем, в плане надежности? Failure Trends in a Large Disk Drive Population: The critical threshold analysis confirms what the charts visually imply: the critical threshold for scan errors is one. After the first scan error, drives are 39 times more likely to fail within 60 days than drives without scan errors.
Т. е. один бэд (физический) => винту нет доверия.
andponomarev
По СМАРТу все нормально кроме 8 унков. Ремапов нет.
Сделайте в MHDD SCAN + Remap ON. Если бэды софтовые, они уйдут. Если физические, скорее всего будут заремаплены и увеличится Reallocated Sectors Count Raw (сейчас там 0).
Понятно, а не стоит ли делать Erase, а потом Erase delays перед процедурой ремаппинга? Точно ли уходят софтовые бэды при SCAN + REMAP ON, или все проблемные блоки просто ремапятся, в независимости от того, софтовые они или физические.
И еще, если можно несколько вопросов (в поиске я был):
1. Что реально делает команда Erase? Это аналог low-level format (т.е. "перемагничивание" поверхности винта?
2. Erase delays - это выборочный "erase" на проблемных блоках?
3. Если, допустим, у меня уже есть заремапленные блоки, можно ли их отремапить обратно? Т.е. проходит ли эта процедура при форматировании (low-level) винчестера?
Заранее прошу прощения, если где чего напутал, но хочется разобраться. Спасибо!
andponomarev не стоит ли делать Erase, а потом Erase delays перед процедурой ремаппинга?
ИМХО нет. Процедура попытки ремапа, как правило, имеет запись в сектор. Для софтбэда достаточно. Физический бэд, по идее, заремапится.
все проблемные блоки просто ремапятся, в независимости от того, софтовые они или физические
Зависит от алгоритма в самом винте. Бывают винты, ремапящие при чтении (гениальное изобретение ). AFAIK Сигейт ремапит только при записи.
Что реально делает команда Erase?
Записывает определенный паттерн (нули, скорее всего) в каждый сектор. Ничем не отличается от обычной записи. Перемагничивание, естественно, происходит, иначе как Вы запишите сектор?
LowLevelFormat'а в исконном понимании уже давно нет (в универсальных утилитах).
Erase delays - это выборочный "erase" на проблемных блоках?
Да, именно на блоках (при ремапе - на отдельных секторах). Т. е. один сектор в блоке медленный/дефектный - перезапишется весь блок (256 секторов).
можно ли их отремапить обратно
Универсальными утилитами - нет. Система "нипель" .
Вендор-комндами "разремапить" можно, но объем гемора по поиск и изучению необходимых материалов не стоит одного тухлого винта.
Насчет Low Level формата (LLF). На правах ИМХО .
Старые винты при записи в сектор переписывали только поля DATA и ECC. LLF для них заключался в перезаписи всех полей сектора.
Современный винт при записи переписывает весь сектор полностью. Поэтому LLF происходит как бы при каждой записи сектора. Однако, количество секторов на треке для каждой стороны и каждой зоны (по радиусу выделяется несколько зон) различно, и эти параметры могут меняться в процессе самонастройки винта. Самонастройка выполняется специальными командами и процедурами и, насколько я знаю, называется SelfScan или Burn. Результаты самонастройки записываются в область данных служебки (обычно на блины, хотя в некоторых Фуджах - на флэшку) и называются "адаптивы". Так вот, этот процесс самонастройки можно в каком-то смысле назвать LLF, но форматируются не отдельные сектора, а вся рабочая область.
Извиняюсь за возможные неточности и глюки.
Старые винты при записи в сектор переписывали только поля DATA и ECC. LLF для них заключался в перезаписи всех полей сектора.
Не только, в старых винтах при LLF прописывались поля синхронизации данных и адресный маркер сектора
Так как позицианирование происходило либо засчет шагового двигателя, либо специально выделенной серво-поверхности.
Там же в адресных метках помечались и сбойные сектора.
Теперь доступа стандартными командами к адрессным маркерам секторов нет. Все это уже функции микропрограммы харда. А за сбойными секторами следит спец механизм дефектных листов - транслятор. И серво-разметка находится там же на треках. И записывается она только на заводе - сервоврайтером.
ECC же попрежнему доступна по командам длиной записи и чтения.
Только к LLF это неимеет ни какого отношения.
То есть теперь по стандартным командам только сами данные+ECC в секторе доступны, как по чтению так и по записи. Весь остальной механизм низкоуровнего формата скрыт в микропрограмме.
Burn или Self test c большой натяжкой можно назвать LLF. скорее это очень хороший внутренний дефектоскоп харда. По которому настраиваются адаптивы и формируются таблицы дефектов.
andponomarev а что "физически" происходит при команде "Erase"?
Перезаписываются сектора (произвольным паттерном, обычно нули). Что физически происходит при перезаписи сектора? Ну, собственно, записываются данные и ECC, а также сервисные поля сектора типа DAM (не путать с серворазметкой), формат сектора индивидуален для каждого вендора (AFAIK). Что происходит при записи вообще? Меняется намагниченность участка магнитного покрытия . Ну а дальше - строение вещества и квантовая механика .
Спасибо, тогда переформулирую: каким образом при команде Erase "уменьшается" время чтения блока, т.е. каким образом убираются "bad blocks"? Вот это мне неясно.
andponomarev
Упрощенно это выглядит так.
Жесткий диск работает под управлением микропрограммы. Если при записи в сектор (у некоторых моделей при чтении) возвращается ошибка, то микропрограмма заменяет этот сектор на резервный (ремап).
И в тему пара цитат из документации на victoria for dos v.3.5.
Цитата:
BB = Fujitsu Remap
Ремаппинг винчестеров FUJITSU. Только для моделей MPG и старше
(новые накопители 2,5'). На других не работает. Использует недоку-
ментированные возможности контроллера HDD FUJITSU. Способен скры-
вать не только явные, но и намечающиеся дефекты (задержки). Не реко-
мендуется совмещать Fujitsu Remap с нелинейными видами чтения -
из-за термокалибровки, которую эти винчестеры выполняют между цикла-
ми позиционирования, может произойти задержка, и как следствие - по-
мещение нормального сектора в дефект-лист.
Q: Почему бы это не сделать для остальных моделей?
A: Потому что это усложнит программу и оставит часть ремонтников HDD без работы
Цитата:
Некоторые винчестеры (новые Maxtor, некоторые экземпляры Samsung
SP0802N) производят ремап псевдо-дефектов при чтении, поэтому будьте
осторожны, во избежании засорения пользовательского дефект-листа.
Автор считает это недосмотром производителей винчестеров, а также
ошибками ремонтников, если опция ремапа чтением "включилась" после
некорректного ремонта, и не обязан отвечать за них. Ремап чтением
_пока_ не замечен у накопителей Seagate, Fujitsu, на остальных смот-
рите сами.
FAQ
Поиск
Пользователи
Группы
Регистрация
Профиль
Войти и проверить личные сообщения
Вход
Накопители. Восстановление информации и ремонт
Write Error Rate 200 200 51 0 Ok
). AFAIK Сигейт ремапит только при записи.
