как сделать ремап подозрительных на бэд (но пока еще не бэд) секторов диска
 

Вот собственно ситуация. Имеется 320гб sata-диск от самсунга, модель не помню. в начале диска имеется порядка 30 - 40 блоков, которые в mhdd имеют слишком большое время доступа, порядка 500-600мс. Эти блоки располагаются примерно в 3-4 группах на первых 30гб диска, по сути на С. В рез-те ОС WinXP грузится еле (минут 7) и вообще на все реагирует заторможенно. А превращать 30гб в неразмеченную область как-то не хочется. Можно ли как - нибудь заремапить или хотя-бы заблокировать сбойные сектора??

Простыми методами нельзя,
только сам хард определяет прятать или нет.
Не забываете, что 40, это не сектора, а блоки по 256 секторов.
Листа A не хватит, чтобы все запрятать.
Если найдете на него бурн комплект, можете запустить, он возможно справится.
Либо спрячет все в заводские листы дефектов, либо запилит диск окончательно.
Возможно нужно слабую голову отключить, станет 200-кой

Можно попробовать использовать erase delays, установив в конфиг. файле время отсечения равным нижнему пределу соотв. блока (т.е. меньше 500).
Учти:

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

Я бы вообще не рекомендовал использовать подобное устройство для хранения сколько-либо ценной информации. А в целом - только вариант изоляции поврежденного пространства, с запасом меса во избежание рецидива. Тем более, что для 320-ки 40гб потерь - это меньше пятой части.

Tomset, что в блоке по 256 секторов это я думаю всем ясно, тем более постоянно крутится в mhdd внизу, насчет бурн комплекта можно поподробней плиз, я про такое только пару раз слышал.
насчет слабой головы не уверен, если слабая голова то, глюки вылазили бы с какой-либо переодичностью, это было бы видно на скане, а так несколько глючных блоков, абсолютно не связанных, разбросанных в кучках по С.. А erase delays забивает резервную область или просто "изымает" сектор из использования??

"настоятельно рекомендует" ж.диску обратить внимание на указанные сектора. Тем не менее,

Ровно то же делает и MHDD и Victoria при исполнении команды Remup. Или erase delays это особо убедительно делает? Впрочем я другое спросить хотел: Можно ли не со слабой, а с сильной головой откушать у диска сектора не в конце диска, а в начале? Речь то шла о "медленных" секторах в начале диска. Я к чему спрашиваю - с помощью команды NHPA можно уменьшить объем только с хвоста диска, с начала - никак. Других инструментов в ATA/ATAPI стандарте вроде как для этого не предусмотренно... Или я ошибаюсь? Может просто пожертовать этими 30Г, создать раздел, можно скрытый и хранить там всякий хлам как на чердаке. Ну будет у вас нестандартная MBR - кому это мешает? А то 7 мин - это слишком...

расскажи где и как это называется, делается. Т.к. у меня MHDD на hirens bootCD и никакого конфиг. файла я там не нашел ни на CD ни на RamDrive при старте с оного, или я ошибаюсь??

Sanek-tx,
Не будет самсунг ремапить медленные, его иной раз и реальные беды не упросишь заремапить. :)
А с Бурном, поиском поищите в гугле/яндексе , информации полно.
Но для одного харда, слишком накладно учиться запускать бурны.
Первые харды при обучении "бурнению" обычно отправляются к проотцам.
Очень много нюансов нужно знать, которые только опытом приобретаются.

и отформатировать его в FAT.

IMHO, в данном случае нужно дисковым редактором пометить плохие сектора в бэды на уровне файловой системы, т.к.
я раньше для этого пользовался Norton Disk Editor, а что используют сейчас?

зачем???

судя по практическим результатам - remap словесно убеждает, а erase - по доброму улыбаясь, бьет по почкам ;)
>
MHDD FAQ, вопрос 36 в первом сообщении.
>
ну, будет или нет - выяснить можно, только запустив и зациклив на ночь ;). А вот со второй частью соглашусь. Хотя были случаи, когда MHDD с remap'ом Samsung'a не справлялась, а вот Victoria - на раз... вот и говорите после этого, что решение принимает ж.диск.. ;)
>
да-да-да, Normal, просветите нас с коллегой.. :)

Ну... возможно установив при этом min. размер кластера будет какое-то улучшение скорости "читаемости".

А по теме автору, мною недавно был куплен в магазине новый WD 1 Tб и после подключения его я просканировал поверхность в Victoria, был обнаружен 1 сектор >500 ms, запустив в Victoria remap он исчез. Причем не нужно при этом весь объем диска гонять, а запустить scan прописав начальный и конечный LBA сразу после последнего "медленного" сектора.
И причем гадание ни к чему не приведет, пока действительно не попробывать.

Всем доброго времени суток.
Хочу сразу сказать, что заставить ентот хард (кстати модель HD322HJ) заремапить "медленные" сектора не удалось :( (как и предполагалось ранее).
Пришлось перебивать разделы. Винду переставлять не хотелось, но придется, тк Ghost упорно отказывался сливать образ, ссылаясь на ошибки ФС.
Также попутно при сканировании в mhdd обнаружилась интересная вещь: неоторые "медленные" сектора как-бы меняют свое положение. Например при сканировани области в начале диска (примерно 5гб) постоянно появлялось WARNING на LBA 6176355 и 2654040, а еще появлялся WARNING на LBA 2878645. при повторной проверке первые 2 остались, а последний стал на LBA 2934795, при след проверках первые остались как и было в начале, а 3-й Warning скакал в области lba 27xxxxx-29xxxxx. естественно erase delays не дал результата!
похожее наблюдалось еще в нескольких местах на всем жестком. Кто нибудь может это объяснить!!?? :o

Кстати попутно сравнивая SMART c 320-ки со своей 500 (тоже самсунг) заметил
во-первых ни одного заремапленого сектора, и в очереди на ремап ничего тоже нет (как ранее и писал)
во -вторых слишком высокий показатель write error rate(val/wrst/tresh/raw) - 99/98/0/4116 у меня же на 500-ке - 100/100/0/0. (в прог-ме Victoria 4.46b fr (Win)). Насколько я понимаю это характеризует кол-во ошибок записи, насколько это существенно?

Винчестер TOSHIBA 320 GB 2.5" начал свою жизнь в 2008 году в чреве свежекупленного ноутбука. Тут же был изъят и вставлен в USB-кейс, а на его место в ноут установлен 500 GB хард. В декабре 2009 года Тошиба перестал использоваться как переносной носитель информации и был установлен в seedbox/NAS, где и проработал благополучно до конца июля этого года, когда uTorrent начал выдавать ошибки CRC (ошибка контрольной суммы). Хард был подвергнут анализу:
http://img577.imageshack.us/img577/3...martbymhdd.jpg

Затем я скинул с него все данные (несколько файлов скопировать не удалось из-за наличия плохочитаемых, а по сути вовсе нечитаемых из под винды секторов) и провёл ERASE DELAYS:
http://img407.imageshack.us/img407/1...hdderasepe.jpg

Зафиксировал результат:
http://img38.imageshack.us/img38/379...martbymhdd.jpg
и уже на следующий день увидел 5 пендингов.
После этого мне пришлось объявить об окончании службы харда и отправить на пенсию - я изъял его из сидбокса и воткнул в USB-кейс, чтобы можно было фильмы таскать на работу. Хотя не уверен, что он мне вообще пригодится - мне и флешки хватает чтобы фильмы таскать.

Итого: ровно год Тошиба проработал в USB-кейсе, затем 2.5 года в сидбоксе, после чего стал инвалидом. Это очень мало для харда. Особенно если учесть, что в сидбоксе он почти не работал - он использовался только под хранилище дистрибутивов, которые я редко качал. Поскольку сидбокс работает в режиме 24/7, то видимо, поэтому количество парковок перевалило за 2.5 млн (параметр 193)


Можно ли заремапить пендинги? Или REMAP применима только к бэдам? А ещё все по разному говорят про возможности этих двух комманд - REMAP и ERASE DELAYS. Одни утверждают, что стирание - это функция перезаписи блока, после которой он может "вылечится", но репам может их спрятать, если лечение не помогло, другие, наоборот, говорят, что ERASE DELAYS - тоже что и ремап, только более результативное.

Да даже чисто внешне это вещи совершенно разные .Если был bad в каком-то секторе блока, то:

--- по ERASE DELAYS получаем полностью прописанный нулями блок --- от первого сектора до последнего. Правда не совсем ясно, что в сбойном секторе окажется...

--- по remap информация в других секторах блока (за исключением сбойного сектора) не затирается. Ну а в сбойном секторе информация и так не определена...

ЗЫ А как оно тама внутре ея работает --- мне неведомо...