Проблемы с дисками, восстановление данных, Жесткими, твердотельными, мягкотелыми, круглыми, квадратными Опции

[Hose]

Добрый вечер всем.я тут новенький,хотел бы у вас узнать есть ли какая то программа что может помочь мне в моей проблеме *???Я проверил программой свой винчестер Viktoria у меня нашел 217 оранжевых сектором а так же температура моего винчестера 48 градусов и еще,проверил другой программой "Hard Disk Sentinel"
тоже самое показало за температуру и написала вот такую ошибку..

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

Можно как то это решить вообще???эту проблему??

[Datarecover]

Я пока что ничего "ошибкой трансляции" не называл.

ну "замучиванием" ))

Кстати - понимание этого механизма позволяет придумать еще один дополнительный превентивный способ сильно снизить вероятность такого "замучивания" транслятора. Если при разметке тома задать ему не быстрое, а полное форматирование, то все LBA тома пропишутся в транслятор последовательно, и далее структура транслятора фрагментироваться уже не будет. Можно также после быстрого форматирования прописать весь объем тома последовательной записью, например, файловым тестом записи HD Tune Pro.

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

Я не понимаю как эти действия повлияют снижение "замучивания".

Ну действия которые происходят возможно поменялись в современных системах но в исходника ХП и в брошурах Русиновича описаны именно такие действия .

Когда у тебя записан большой кусок данных линейно - записи о последовательных LBA в трансляторе оказываются рядом, и после первого обращения к этому куску транслятора (пусть его и нужно было поискать, несколько раз обратясь к флешу) и подгрузки его из флеша в DRAM остальные находятся сразу же, и скорость чтения определяется практически скоростью подачи данных из флеша. Более того, так как запись шла линейно - то и данные последовательных LBA укладывались рядом, по 32 LBA в одну страницу записи. То есть - как только хост обратился за первым LBA из такого последовательного потока - в буфер прочитались все 32, и отдача их на следующие запросы будет вестись уже не из флеша, а из буфера самого контроллера. Таким образом - после первого относительно долгого поиска, дальнейшие данные отдаются в темпе чтения страниц с флеша: страницу в буфер всосали, и ее всю на очередные 32 запроса хосту и отправили.

Теперь посмотрим на картинку, когда запрос на чтение попадает на участок транслятора, забитый мелкоблочными обращениями. Чтобы найти физический адрес наших данных, контроллеру нужно прочитать пусть, к примеру, четыре ссылки на участки транслятора, то есть - прочитать четыре 16-килобайтные страницы, и, найдя нужный адрес, прочитать страницу с данными, пятую. На запрос следующего LBA - процесс придется повторить, потому как он не попал в этот же участок транслятора, и на то, чтобы его отдать хосту, нужно прочитать еще пять страниц флеша. И так далее... То есть, на то, чтобы отдать хосту каждые 512 байт, контроллеру с флеша нужно прочитать 80 килобайт, скорость упала в 160 раз.

Спасибо я попробую реализовать эти тесты на R.Tester и посмотрю.