[Evgesha_572]

выложил SMART прследний
сейчас при проверке данного раздела скандиском , система в синий экран не выпадает , будет считать что проблема решена

[minos66]

Evgesha_572, Обратите внимание, что два бэда были все таки не софтовые. Переодически проверяйте смарт - если 5 параметр (еще посматривайте за изменением числа "кандидатов" в бэды - 197) расти не будет - все в порядке. Так же частота (1) и общее число ошибок(195) при передачи данных наводит на мысль о аппаратных проблемах. Но во первых - это может быть следствием разгона, во вторых - tresh еще не достигнут, в третьих - смарт сигейтов сам по себе вызывает много вопросов (лично у меня новый диск показал в 3 параметрах "половинные" значения надежность. Потом они стали медленно увеличиваться. Вот так...). Да и вообще, учитывая, ненулевое значение ошибок передачи данных по внешнему интерфейсу, можно посоветовать несколько раз вытащить-вставить хард, возможно не очень хороший контакт.

[Esdek64]

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

насколько я понимаю, функция REMAP записывает "плохой" сектор в лист исключения и "заменяет" этот сектор хорошим из резерва. При этом, если в плохом секторе была информация, то она теряется. А прога HDD Регенератор именно устраняет дефект и сохраняет имеющуюся в плохом секторе информацию.

[Tomset]

А прога HDD Регенератор именно устраняет дефект и сохраняет имеющуюся в плохом секторе информацию »

Неверно.
Только сам накопитель в состоянии вычитать плохой сектор, если это возможно.
И соответсвенно либо перепишет, либо преназначит его, если есть резервное место.
Когда накопитель не может вычитать сектор, он так и остается в кандидатах (197 Current pending sectors) до следуюшей записи в него.
О невычитанных секторах в смарте присутсвует отметка в атрибуте - 198 Offline scan UNC sectors.
Строго говоря - кандидат, это не один сектор. А запись в логе кандидатов или G-листе (в зависимости от модели), в которой может числится от одного до целого трека секторов.
Во время работы харду некогда долго возиться с плохо читаемыми секторами, раз десять попробовал вычитать и хватит. После чего помечает их, как кандидатов на ремап.
Во время простоя запускается особая долгая процедура различных методов вычитывания плохого сектора/ов.
Ни какая программа лучше самого HDD это не сделает.
Так что ни ремап Виктории, MHDD или Дегенератора, вычитать такой сектор не смогут.
Поэтому они пишут в этот сектор сигнатуру (обычно нули). Если сектор записывается, он соотвественно уходит из кандидатов, если не может записаться - переназначается и уже из кандидатов запись переходит в атрибут - 5 Reallocated sector count.
Целостность данных будет зависеть только от того, куда такой сектор попал.

[ShaddyR]

Esdek64, проще говоря, подытожу: Регенератор "сам" ничего никуда не переносит. Как и все другие, он просто пытается уговорить ж.диск провести ремапинг. Могу сказать из личного опыта: пока при ремапинге информация не терялась. А то, что ты озвучил

записывает "плохой" сектор в лист исключения и "заменяет" этот сектор хорошим из резерва. При этом, если в плохом секторе была информация, то она теряется. »

это ближе к механизму erase обеих программ - как раз деструктивному.

Поэтому они пишут в этот сектор сигнатуру (обычно нули) »

при ремапинге?

[Tomset]

при ремапинге? »

да.
Ремап выпоняет только сам хард.
И он сделает ремап, только если смог вычитать проблемный сектор.
Если не смог вычитать, то ремап будет произведен только при следующей записи в невычитанный сектор.
Собственно вся функция ремапа в подобных программах, многократно производить запись-чтение в проблемный сектор, пока он не прочтется. Причем неизвестно, записался ли он на свое место или переназначился.
В некотрых старых хардах, была возможность включать ремап при чтении. Но в этом случае при работе HDD возникали длительные задержки и достоверность вычитанной информации не гарантировалась. Потому такой режим, использовался только в тестах.

Из программ нет прямого доступа к резервной зоне. Она не в адресном пространстве пользовательской зоны и не имеет адресации в LBA. HDD обрашается к ней только если в G-листе есть запись о переназначении плохого сектора.

[ShaddyR]

Ремап выпоняет только сам хард. »

это понятно. Утилиты могут порекомендовать (в случае erase delays - настоятельно). Но в случае

вся функция ремапа в подобных программах, многократно производить запись-чтение в проблемный сектор, пока он не прочтется »

информация, хранящаяся в секторе, в этом случае терялась бы, не так ли. Но ни в Victoriy, ни в MHDD функция remap деструктивной не называется.

[Tomset]

ни в MHDD функция remap деструктивной не называется »

Правильно, чего деструктировать-то?
В плохих секторах информация уже потеряна. А остальные она не трогает.

[ShaddyR]

В плохих секторах информация уже потеряна. А остальные она не трогает »

н-дя... потеряна, говоришь? Тогда так: лежит архив, бааальшой... не копируется и не открывается, проверяем - точно, на поверхности ж.диска куча БЭДов... производим remap - и читается, и копируется и при тесте ошибок CRC не содержит.. Как-то слишком жива информация, для потеряной
(проверялось не раз: после ремап'а вся информация остается живой и читабельной)

[Evgesha_572]

Результат сканирование MHDD во вложении