 |
Форум iHDD.RU
Ремонт накопителей и восстановление информации
|
|
Ремапы и др.
|
| Автор |
Сообщение |
Shark
Зарегистрирован: 27.09.2005
Сообщения: 156
Откуда: Новокузнецк
|
 Добавлено: Ср, 28 Сен, 2005 12:23 Заголовок сообщения: Ремапы и др. |
 |
|
По поводу 13 пункта FAQ - я бы не сказал, что ремап это посекторный EraseWaits. По крайней мере на IBM с софт бэдами от ремапа никакого толку нет! ИМХО потому что при ремапе не делается сброс накопителя и ремап подвисает (хрюкает) на псевдо бэдах. Нельзя ли добавить сброс перед ремапом?
Еще есть интересная возможность заставить ремапить красно-коричневые блоки таким образом:
при скане натыкаемся на красно-коричневых, анализируем блок, помечаем тормозные сектора как UNC (через makebad), делаем ремап.
И все это в автоматическом режиме. Типа адвансед ремап. |
|
| Вернуться к началу |
|
 |
lepik666
Зарегистрирован: 28.09.2005
Сообщения: 4
|
| Добавлено: Пт, 14 Окт, 2005 10:06 Заголовок сообщения: |
|
|
| А можно узнать как пометить красно коричневых, как UNC? |
|
| Вернуться к началу |
|
|
Antech
Зарегистрирован: 03.10.2005
Сообщения: 657
|
| Добавлено: Пт, 14 Окт, 2005 11:45 Заголовок сообщения: |
|
|
lepik666
как пометить красно коричневых, как UNC?
То есть? Просто сделать их UNC? Команда MAKEBAD. А зачем?
По поводу FAQ 13. Действительно очень странно. Как работает EraseWaits? Я так понимаю, читает блок (как обычно), если воемя доступа >TauMax, записывает весь блок. Но при ремапе эту процедуру можно повторить не раз, причем в применении не к блоку, а к отдельным секторам: с первого раза может не заремапиться. Интересно было бы услышать комментарии Dmitry Postrigan про алгоритм ремапа в MHDD. Если это, конечно, не коммерческая тайна. |
|
| Вернуться к началу |
|
|
maysoft
Зарегистрирован: 27.09.2005
Сообщения: 639
|
| Добавлено: Пт, 14 Окт, 2005 16:16 Заголовок сообщения: |
|
|
| Чтобы сделать ремап, нужно для начала узнать номер сектора, который необходимо заремапить. Единственный 100% способ узнать это — дождаться ответа от накопителя. Если накопителю подать сброс, то никакой ошибки он не вернёт. |
|
| Вернуться к началу |
|
|
hdd
Зарегистрирован: 12.10.2005
Сообщения: 5
|
| Добавлено: Пт, 14 Окт, 2005 20:27 Заголовок сообщения: |
|
|
Ну хорошо: если не возможно заремапить краснокоричневые блоки, существует ли возможность скрыть их при форматировании?
Может кто-нибудь знает программу, где при форматировании можно указать, какой сектор UNC, а какой нет. |
|
| Вернуться к началу |
|
|
Ruterian
Зарегистрирован: 27.09.2005
Сообщения: 59
Откуда: Minsk
|
| Добавлено: Вс, 16 Окт, 2005 01:42 Заголовок сообщения: |
|
|
| maysoft писал(а): | | нужно для начала узнать номер сектора, который необходимо заремапить. Единственный 100% способ узнать это — дождаться ответа от накопителя. Если накопителю подать сброс, то никакой ошибки он не вернёт. |
Если бы драйверы устройств использовали этот принцип, то в мире операционных систем царили бы дополнительные глюки к уже имеющимся 
Накопители действительно возвращают некое число по ошибке, которое по стандарту должно соответствовать номеру дефектного LBA. Но за достоверностью этих данных не обязан следить разработчик ОС. Мало-ли что придет в головы создателям новых моделей винтов... Исключат "возврат адреса" - и приехали! После бэд-блока винт вернет ахинею (например, нули), и драйвер перенаправит чтение/запись следующего блока на ложный/несуществующий адрес. Будет коллоссальный сбой и потеря данных!
Поэтому создатели дисковых программ/драйверов никогда не надеются на HDD, и всегда используют математический рассчет текущего сектора. Обычный счетчик считает все прочитанные LBA, и по нему ОС в любой момент знает текущий сектор (вне зависимости от желания винта выдать нам что-то). В том числе и при ошибке, когда IDE устройство может вообще длительное время не отвечать. Также драйверам не возбраняется посылать сброс в "зависший" винт, что иногда применяют. |
|
| Вернуться к началу |
|
|
maysoft
Зарегистрирован: 27.09.2005
Сообщения: 639
|
| Добавлено: Вс, 16 Окт, 2005 04:34 Заголовок сообщения: |
|
|
| Цитата: | | Если бы драйверы устройств использовали этот принцип, то в мире операционных систем царили бы дополнительные глюки к уже имеющимся |
гм. Я думал мы говорим о верификации, безотносительно ОС и драйверов. При верификации все математические методы просто не канают — нечего вычислять .
| Цитата: | | Накопители действительно возвращают некое число по ошибке, которое по стандарту должно соответствовать номеру дефектного LBA. Но за достоверностью этих данных не обязан следить разработчик ОС. Мало-ли что придет в головы создателям новых моделей винтов... Исключат "возврат адреса" - и приехали! После бэд-блока винт вернет ахинею (например, нули), и драйвер перенаправит чтение/запись следующего блока на ложный/несуществующий адрес. Будет коллоссальный сбой и потеря данных! |
Обычно накопители (за редким исключением) возвращают номер сбойного сектора корректно. Если какая программа/ОС не контролирует ответ накопителя, то это проблемы разработчика. MHDD такую проверку выполняет, и если винчестер вернул бред, то будет считаться ошибкой первый сектор в блоке. Такая проверка реализуется одной строчкой и я не вижу здесь никаких проблем…
| Цитата: | | Поэтому создатели дисковых программ/драйверов никогда не надеются на HDD, и всегда используют математический рассчет текущего сектора. Обычный счетчик считает все прочитанные LBA, и по нему ОС в любой момент знает текущий сектор (вне зависимости от желания винта выдать нам что-то). В том числе и при ошибке, когда IDE устройство может вообще длительное время не отвечать. Также драйверам не возбраняется посылать сброс в "зависший" винт, что иногда применяют. |
Вот-вот. Например, мой копировщик просто плюёт на ответ накопителя, а считает, сколько реально секторов получено от накопителя. Но мы ведь говорим о верификации, где нет никаких секторов!
Что можно сделать?
Можно сделать так: если верификация натыкается на сбойный блок, или блок с задержкой, послать накопителю сброс, и тут же прочитать этот же участок командой чтения. Потери небольшие, 0,3-0,5 секунд на блок. Есть ли смысл? |
|
| Вернуться к началу |
|
|
and
Зарегистрирован: 27.09.2005
Сообщения: 29
Откуда: г. Гомель, Беларусь
|
| Добавлено: Вс, 16 Окт, 2005 11:11 Заголовок сообщения: |
|
|
| Кажется, мы опять возвращаемся к вопросу о канувшей команде read ;-) |
|
| Вернуться к началу |
|
|
Ruterian
Зарегистрирован: 27.09.2005
Сообщения: 59
Откуда: Minsk
|
| Добавлено: Вс, 16 Окт, 2005 12:54 Заголовок сообщения: |
|
|
| maysoft писал(а): |
гм. Я думал мы говорим о верификации, безотносительно ОС и драйверов. При верификации все математические методы просто не канают — нечего вычислять . |
Если при задержке верифицировать это место с размером блока =1 сектор, то на следующей задержке счетчик укажет на искомый сектор. Можно вместо верификации читать его, принцип тот же.
| Цитата: | Что можно сделать?
Можно сделать так: если верификация натыкается на сбойный блок, или блок с задержкой, послать накопителю сброс, и тут же прочитать этот же участок командой чтения. Потери небольшие, 0,3-0,5 секунд на блок. Есть ли смысл? |
Я когда-то думал на тему, есть ли смысл удлинять проверку поверхности на эти доли секунд (которые вносят ошутимые потери времени при плохом состоянии HDD. Решил, что смысл есть (все-таки это инструмент, а не игрушка), но не в ущерб скорости.
В результате в Victoria 3.x появился второй вид скана поверхности - режим дефектоскопа. Достаточно нажать на клавишу SPACE во время скана, или выбрать соответствующий пункт меню, чтобы этот алгоритм включился (таймауты можно регулировать).
| Цитата: | | Например, мой копировщик просто плюёт на ответ накопителя, а считает, сколько реально секторов получено от накопителя. |
Ты сам говоришь этим, насколько важно не надеяться на накопитель во время выполнения стратегических задач. Ошибка в верификации ни к чему не приведет. Максимум - юзер заплачет от неверных циферек на экране Ошибка хотя-бы на 1 сектор при копировании станет причиной потери или разрушения информации в копии. Ошибка в драйвере (функция которого - то же копирование HDD -> ОЗУ ПК) приведет к неверно полученным данным. |
|
| Вернуться к началу |
|
|
|
|
FAQ
Поиск
Пользователи
Группы
Регистрация
Профиль
Войти и проверить личные сообщения
Вход
Накопители. Восстановление информации и ремонт
