разметить винч 1500 Samsung

Жесткие диски, как электромеханические устройства, один из самых ненадежных компонентов современного компьютера. Не смотря на то, что в большинстве случаев срок службы последних соизмерим, и даже превосходит время их эксплуатации до момента морального устаревания и замены более новыми моделями, все же отдельные экземпляры выходят из строя в течение первых месяцев эксплуатации.
Выход жесткого диска из строя это самое худшее, что может случиться с вашим компьютером, так как при этом необратимо теряются накопленные на нем данные. И если резервная копия по какой-то причине отсутствует, то суммарный ущерб от поломки заметно превышает копеечную стоимость современных винчестеров.
Многие фирмы, пользуясь ситуацией, предлагают свои услуги по восстановлению информации с вышедшего из строя накопителя. Очевидно, это обходится недешево, и целесообразно только когда на диске действительно находилось что-то невероятно ценное. В противном случае легче просто смириться с поломкой.
Ремонт жестких дисков требует специального оборудования и практически невозможен в домашних условиях. Так, например, только для вскрытия герметичного контейнера, необходима особо чистая от пыли комната. Казалось бы, положение безнадежно и нечего и помышлять восстановить поломанный диск в домашних условиях. Но к счастью не все поломки настолько серьезны, и во многих случаях можно обойтись для ремонта подручными (а иногда чисто программными средствами).
Одним из самых частых отказов винчестеров фирмы Western Digital (а так же и некоторых других) выглядит следующим образом - жесткий диск не опознается BIOS, а головки при этом отчетливо стучат. Скорее всего, по какой-то причине не работает блок термокалибровки, и устройство не может обеспечить нужный зазор между головкой и рабочей поверхностью \"блина\". Обычно это происходит при отклонении от температурного режима эксплуатации, например в зимнее время, когда жесткие диски в плохо отапливаемых помещениях \"выстывают\" за ночь (при температуре 18°-21° жесткий диск часто может исправно функционировать и с испорченным механизмом термокалибровки)
Попробуйте дать поработать винчестеру в течение нескольких часов, что бы он мог прогреться, при этом рано или поздно последний попадет в необходимый диапазон температур и работоспособность (возможно временно) восстановиться. Разумеется, что первым делом нужно скопировать всю информацию, поскольку работоспособность такого диска уже не гарантируется, хотя на винчестере с нерабочей системой термокалибровки иной раз можно поработать достаточно длительное время, но все же лучше не рисковать. (То же относится и к устаревшим моделям без термокалибровки; часто они оказываются зависимыми от температурного режима, что с ростом износа винчестера становиться заметно все сильнее и сильнее)
Вторым по распространенности отказом является выход из строя модуля диагностики при полной исправности остальных компонентов. Как бы это не было парадоксально, но это факт - полностью рабочий винчестер не проходит диагностику. При этом в регистре ошибок (порт 0х1F1 для первого жесткого диска) могут содержаться следующие значения:
Бит Содержимое Источник ошибки
7 0 Ошибка master диска
7 1 Ошибка slave диска
2-0 011 Ошибка секторного буфера
2-0 100 Ошибка контрольной суммы, не устранимая избыточным кодированием
2-0 101 Ошибка микроконтроллера


При этом разные BIOS-ы могут по различно реагировать на такую ситуацию, которая, однако, сводится к одному - жесткий диск не определяется и не \"чувствуется\".
Однако на уровне портов ввода \\ вывода устройство функционирует отлично. Заметим, что существуют такие материнские платы (особенно среди новых моделей), которые, обнаружив ошибку микроконтроллера винчестера, просто отключают питание жесткого диска.
Несложно написать драйвер для испорченного таким образом диска, который обеспечит работу с ним через высокоуровневый интерфейс Int 0x13. Например, следующая процедура обеспечивает посекторное чтение и запись через порты ввода вывода для первого жесткого диска в CHS режиме.
LBA mode для упрощения понимания не поддерживается. Необходимую техническую информацию обычно можно найти на сайте производителя вашего жесткого диска.
HDD_IO:
MOV DX, 1F2h ; Число секторов
MOV AL, 1 ; Читаем один сектор
OUT DX, AL ; ^
INC DX ; Номер сектора (считая от 1)
OUT DX, Sector ; Какой сектор читать
INC DX ; Младший байт номера цилиндра (считая с 0)
MOV AL, CylLow ; ^
OUT DX, AL ; ^
INC DX ; Старший байт номера цилиндра
OUT DX, AL ; ^
MOV AL, 10100000B ; Режим - диск #0, CHS mode
OR AL, Head ; Головка (считая от 0)
INC DX ; ^
OUT DX, AL ; ^
INC DX ; Командный регистр
MOV AL, command ; операция #2 чтение\\#3 запись
OUT DX, AL ; ^
MOV DX, 1F0h ; Регистр данных
MOV CX, Sector_size; Размер сектора
LEA SI, Buffer ; Указывает на буфер данных
MOV AL,command ; Код команды.
AND AL,1 ; Четный (чтение) или нет (запись)
JNZ write ; --> пишем
REP MOVSB ; Читаем данные
RET ; --/ Write:
REP STOSB ; Записываем
RET ; --/ BIOS IDE Результат
Максимальное число секторов на дорожке 63 255 63
Максимальное число головок 255 16 16
Максимальное число цилиндров 1024 65536 1024
Максимальный размер диска 8.4Гб 136.9Гб 528Мб


Этот фрагмент может служить вполне работоспособным ядром для драйвера 16-ти разрядного режима. Для упрощения понимания не включена задержка, после каждого обращения к порту. (Вообще-то, в зависимости от соотношений скорости вашего процессора и контролера диска эта задержка может и вовсе не потребоваться; в противном случае рекомендуется читать регистр статуса 0x1F7 дожидаясь готовности контроллера)
При этом даже не будет особой нужны спешить менять такой жесткий диск на новый и с подобной неисправностью можно успешно проработать не год и не два. Последнее, правда, лишь при условии, что все используемое вами ПО не будет конфликтовать с нестандартным драйвером. Учитывая, что писать его, скорее всего, придется вам, поскольку не известно ни одной коммерческой разработки в этом направлении, а все любительские страдают большой забитостью \"под себя\". Так, например драйвер от KPNC hddFix3a поддерживает только Primary Master до пятисот мегабайт и не работает в среде Windows 95 (поскольку был разработан на год раньше ее появления).
Более легкий, но не всегда осуществимый путь - запретить тестирование жестких дисков BIOS-ом или, по крайней мере, игнорировать результаты оного. Как это осуществить, можно прочесть в руководстве на Вашу материнскую плату (или обратится за помощью к технической поддержке фирмы производителя, поскольку в руководствах пользователя такие тонкости нередко опускают). Например, попробуйте установить \'Halt on\' в \'Never\' или перезаписать Флеш-Биос, модифицировав его так, что бы тот не выполнял подобную проверку. Если Вам повезет, жесткий диск заработает!
Однако, иногда все же случаются и аппаратные отказы. Чаще всего это происходит с винчестерами фирмы \'SAMSUNG\' и \"CONNER\'. Контроллеры последнего часто сделаны не очень качественно и не редки случаи отказа модуля трансляции мультисекторного чтения \\ записи. Если это не будет обнаружено внутренним тестом устройства, то такой жесткий диск вызовет зависание операционной системы на стадии ее загрузки. Для предотвращения это достаточно добавить в CONFIG.SYS ключ \"MULTITRACK=OFF\" и отключить аналогичные опции в BIOS-е. При этом, проиграв в скорости, все же можно заставить жесткий диск сносно работать. Понятно, что эксплуатировать восстановленный таким образом диск, не рационально по причине потери быстродействия. Лучше приобрести новый, на который и скопировать всю информацию. С другой стороны такой жесткий диск все же остается полностью рабочим и успешно может служить, например, в качестве резервного.
На том же CONER-е эпизодически вылетает блок управления позиционированием головок так, что последние уже не могут удержаться на дорожке и при обращении к следующему сектору немного \"уползают\". При этом считывание на выходе дает \"мусор\", а запись необратимо затирает соседние сектора. Бороться с этим можно позиционированием головки перед каждой операцией записи \\ чтения, обрабатывая за один проход не более сектора. Понятно, что для этого необходимо вновь садиться за написание собственного драйвера. К счастью он достаточно простой (можно использовать аппаратное прерывание от жесткого диска Int 0х76 IRQ14, вставив в тело обработчика команду сброса контроллера)
PUSHA ; Сохранить все регистры в стеке
XOR AH,AH ; AH = 0 сброс контроллера жестк. диска
INT 13h ; ^
MOV AL,21h ; Разблокировать контроллер прерываний
MOV 21h,AL ; ^
POPA ; Восстановить все регистры
IRET ; Возврат из прерывания

В данном случае подразумевается, что контроллер используемого жесткого диска проводит рекалибровку головки во время операции сброса. Некоторые модели этого не делают. В этом случае придется прибегнуть к операции позиционирования головки (функция 0xC дискового сервиса 0x13). Первые от вторых можно отличить временем, требуемым на сброс контроллера. Понятно, что электроника \"сбрасывается\" мгновенно, а позиционирование головки требует хоть и не большого, но все же измеримого времени. Современные модели с поддержкой кэширования этого часто не делают или \"откладывают\" операции с головкой до первого к ней обращения. Разумеется, что в этом случае кэширование придется выключить. Большинство BIOS позволяет это делать без труда, и нет нужды программировать контроллер самостоятельно.
В другом случае вышедший из строя блок позиционирования (трансляции) подводит головки вовсе не к тому сектору, который запрашивался. Например, головки могли физически сместиться с оси, \"уползая\" в сторону. Разумеется, этот дефект можно скорректировать программно, достаточно проанализировать ситуацию и логику искажения трансляции. Многие модели позиционируют головку, используя разметку диска, что страхует от подобных поломок (к сожалению, сейчас от такого подхода большинство фирм отказались, выигрывая в скорости).
Конечно, все описанные программные подходы в действительности не устраняют неисправность, а только позволяют скопировать с казалось бы уже нерабочего винчестера ценные и еще не сохраненные данные. При этом ни к чему писать универсальный драйвер для win32 и защищенного режима. Вполне можно ограничиться DOS-режимом. для копирования файлов его должно оказаться достаточно, конечно за исключением тех случаев, когда диск был отформатирован под NTSF или другую не поддерживаемую MS-DOS систему. К счастью для многих из них есть драйвера, которые позволяют \"видеть\" подобные разделы даже из \"голой\" MS-DOS. В крайнем случае, можно ограничиться посекторным копированием на винчестер точно такой же топологии. При этом совершенно не имеет значение используемая файловая система и установленная операционная система.
К сожалению посекторно скопировать диск на винчестер с иной топологий трудно, но возможно. Дело в том, что многие современные контроллеры жестких дисков позволяют пользователю менять трансляцию произвольным образом. Для этого необходимо приобрести винчестер, поддерживающий LBA-режим (а какой из современных жестких дисков его не поддерживает?). При этом он может быть даже большего объема, нежели исходный, но это никак не помешает копированию. Другой вопрос, что без переразбиения скопированный таким образом диск не \"почувствует\" дополнительных дорожек и следует запустить Norton Disk Doctor, который устранит эту проблему.
Достаточно часто нарушается вычисление зон предкомпенсации. Дело в том, что плотность записи на разных цилиндрах не одинакова, т.к. линейная скорость растет от центра к периферии. Разумеется, гораздо легче постепенно уплотнять запись, нежели искать некий усредненный компромисс. На всех существующих моделях плотность записи изменяется скачкообразно и на последних моделях программно доступна через соответствующие регистры контроллера. При этом значения, выставленные в BIOS практически любой жесткий диск (IDE) просто игнорирует.
Вообще-то предыдущие модели не имели с этим проблем, и только винчестеры, выпущенные в течение последней пары лет, склонны к подобным поломкам. Скорее даже не поломкам, а сбоям, в результате которых искажается хранимая где-то в недрах жесткого диска информация. Если контроллер позволяет ее программно корректировать, то считайте, что ваш жесткий диск спасен. Конечно, придется пройти сквозь мучительные попытки угадать оригинальные значения, однако это можно делать это и автоматически перебором до тех пор, пока винчестер не начнет без ошибок читать очередную зону. Помните, что любая запись на диск способна нарушить низкоуровневую разметку винчестера, после чего последний восстановлению не подлежит и его останется только выкинуть. Производите только чтение секторов!
Если же контроллер не позволяет программно управлять предкомпенсацией, то еще не все потеряно. Попробуйте перед каждым обращением делать сброс контроллера, а точнее рекалибровку его (команда 1xh). В некоторых случаях это срабатывает, поскольку с целью оптимизации скорости обмена предкомпенсацией обычно управляет не один блок. И, кроме того, иногда контроллер кеша не учитывает прекопенсацию, а его сброс реализует последнюю аппаратно. К сожалению, это по большей части догадки и результаты экспериментов автора, т.к. технические документации фирм-производителей по этому поводу очень отрывисты и не полны, а местами противоречат сами себе. Или попробовать перезаписать микрокод контроллера (команда 92h). Конечно, последнее доступно только для специалистов очень высокого класса, но все же ведь доступно! Замечу, что не все контроллеры поддерживают такую операцию. С другой стороны это и хорошо, т.к. уменьшает вероятность сбоя и не дает некорректно работающим программам (вирусам в том числе) испортить сей дорогой девайс.
Жесткие диски от Samsyng обладают еще одной неприятной особенностью - часто при подключении шлейфа \"на лету\" при включенном питании они перестают работать. Внешне это выглядит так - индикатор обращения к диску постоянно горит, но диск даже не определяется BIOS, или определяется, но все равно не работает.
Близкое рассмотрение показывает, что на шине пропадает сигнал готовности устройства. А в остальном контроллер остается неповрежденным. Разумеется, что если не обращать внимание на отсутствие сигнала готовности, то с устройством можно общаться, делая вручную необходимые задержки (поскольку физическую готовность устройства уже узнать не представляется возможным, приходится делать задержки с изрядным запасом времени).
При этом, к сожалению, придется отказаться от DMA - mode (а уж тем более ultra-DMA) и ограничиться PIO 1 (ну с небольшим риском PIO 2) режимом. Конечно, при этом писать соответствующий драйвер вам придется самостоятельно. Разумеется, что скорость обмена в режиме PIO 1 по сегодняшним меркам просто смехотворна, и не годиться ни для чего другого, кроме как копирования информации со старого на новый винчестер, но некоторые нечистоплотные продавцы компьютерной техники как-то ухитряются устанавливать подобные экземпляры на продаваемые машины. Будьте осторожны! Учитывая, что написание подобных драйверов для win32 трудоемкое занятие, большинство ограничивается поддержкой одной лишь MS-DOS, но вовсе не факт, что компьютер, демонстрирующий загрузку win95, содержит исправный, а не реанимированный подобным образом жесткий диск.
У тех же Самсунговских дисков при подключении \"налету\" может появляться другой неприятный дефект - при запросах на чтение контроллер периодически \"повисает\" и не завершает операцию. В результате \"замирает\" вся операционная система (впрочем, Windows NT с этим справляется, но вероятно не всегда). С первого взгляда кажется, что с этого винчестера несложно скопировать ценные файлы, но при попытке выполнить это, выясняется, что диск \"зависает\" все чаще и чаще и копирование растягивается в бесконечность.
Однако если выполнить сброс контроллера, то можно будет повторить операцию. Это можно сделать аппаратно, подпаяв одну кнопку, на линию сброса и статуса. Последнее нужно для указания на ошибочную ситуацию, что бы операционная система повторила незавершенную операцию. Если последнее не сделать, то часть секторов не будет реально прочитана (записана). Или можно выполнять сброс автоматически, по таймеру, например.
Чтобы не сталкиваться с подобной ситуацией, никогда не стоит подсоединять \\ отсоединять винчестер при включенном питании. Очень часто это приводит к подобным ошибкам, хотя производители других фирм, по-видимому, как-то от этого все же защищаются, ибо аналогичной ошибки у них практически не встречаются. Но все же не стоит искушать судьбу. От аппаратных ошибок теперь перейдем к дефектам поверхности. Заметим сразу, что последнее встречается гораздо чаще и намного коварнее. Т.к. если электроника в умелых руках всегда поддается восстановлению, то дефекты поверхности едва ли. Обычно это безнадежная ситуация в которой мало, что можно предпринять. Но главной целью все же будет спасти как можно больше уцелевших данных. Довольно часто это удается. Возьмем такую банальную ситуацию как ошибка чтения сектора. Собственно маловероятно, что бы сектор был разрушен целиком. Чаще всего \"сыплется\" только какая-то его часть, а все остальные данные остаются неискаженными.
Существуют контроллеры двух типов. Первые, обнаружив расхождение контрольной суммы считанного сектора, все же оставляют прочиненные данные в буфере, и позволяют их извлечь оттуда, проигнорировав ошибку чтения. Вторые либо очищают буфер, либо просто не сбрасывают внутренний кэш в результате чего все равно прочитать буфер невозможно. На практике обычно встречаются последнее. При этом сброс кеша можно инициировать серией запросов без считывания полученных данных. Кеш при этом переполняется, и наиболее старые данные будут вытолкнуты в буфер. Остается их только прочесть. Конечно, это крайне медленно, но, к сожалению, универсальной команды сброса кеша не существует. Разные разработчики реализуют это по-своему (впрочем, иногда это можно найти в документации на чипы, используемые в контролере). Westerd Digitel сообщает в техническом руководстве, что при длинном чтении сектора без повтора, контроль сектора не выполняется, и он будет-таки целиком помещен в буфер. Кстати, так и должно быть по стандарту. Увы, остальные фирмы он него часто отклоняются по разным соображениям.
Остается определить какие же из прочитанных данных достоверные, а какие нет (если этого не видно \"визуально\" - например, в случае текстового или графического файлов)? Разумеется, в подобных рамках задача кажется неразрешимой, но это не совсем так. Дело в том, что можно произвести не только короткое, но и длинное чтение (0х22h req PIOin read long with retry) для чего можно использовать следующую процедуру:
MOV AH,0Ah ; Длинное чтение сектора с CRC
MOV AL,NumSect ; Число секторов для чтения
MOV CH,Cyl ; Цилиндр (младшие восемь байт)
MOV CL,Sect ; Число секторов
MOV DH,HEad ; Головка
MOV DL,80 ; HDD #0
LES BX,[lpBuff] ; Указатель на буфер

При этом кроме собственно данных читаются так же и корректирующие коды. Автоматическая коррекция не выполняется (хотя некоторые контроллеры это реализуют аппаратно и не могут отключить авто коррекцию; в документации этот момент, кстати, не уточняется). Как правило, используются корректирующие коды Рида-Соломона, хотя последнее не обязательно. Математические законы позволяют не только определить место возникновения сбоя, но и даже восстановить несколько бит. При больших разрушениях можно определить только место сбоя, но достоверно восстановить не удается.
Модуляция при записи такова, что все биты, стоящие справа от сбойного уже не достоверны. Точнее, не все, а только в пределах одного пакета. Обычно за один раз записывается от 3 до 9 бит (необходимо уточнить у конкретного производителя) и содержимое остальных пакетов, как правило, остается достоверным.
Самое интересное, что зачастую сбойный пакет можно восстановить методом перебора! При этом можно даже рассчитать, сколько вариантов должно получиться. Учитывая хорошую степень \"рассеяния\" корректирующих кодов можно сказать, что не очень много. И таким образом можно восстановить казалось бы безнадежно испорченные сектора, а вместе с ними и файлы, расположенные \"поверх\" последних.
Выше были перечислены наиболее типичные случаи отказов жестких дисков, которые поддавались чисто программному восстановлению если уж не винчестера, то хотя бы хранимых на нем данных. Разумеется, что иногда жесткий диск выходит из строя полностью (например, при неправильно подключенном питании, скачках напряжения) вибрации или ударов, а то и просто откровенного заводского брака.
Есть один старый проверенный способ - найти жесткий диск такой же точно модели и заменить плату электроники. К сожалению, последнее из-за ряда конструктивных особенностей все реже и реже бывает возможно, а уж дефекты поверхности этот способ и вовсе бессилен вылечить.
Поэтому, берегите свой жесткий диск и почаще проводите резервное копирование. Помните, что самое дорогое это не компьютер, а хранимая на нем информация!
nodevice.ru

Некоторое время назад скопировал на флеш архив программок,фотки переносом.Посмотрел - на флешке все лежало. Но по недосмотру просто забыл флеш на несколько дней в USB-порту .Сегодня понадобился файлик оттуда.
Обнаружив к собственному удивлению флешку воткнутую в порт, попытался ее открыть - не тут то было.
Винда требует формата...Пробовал в разных дырках, на другом компе - результат один.
Слетел загрузочный сектор..как ? - без понятия...Попытки восстановить его не увенчались успехом.
Пробовал несколько прожек - мне оказалось не по зубам.
А вот с помощью testdisk-6.11.3 мне удалось в короткий срок вытащить свои 1.5 Гб практически без потерь. Некоторые фотки имена потеряли - но это ведь не криминал.

некоторые отзывы о пробовавших этот tool говорили о том, что он помог им вроде как решить вопрос с нормальной читабельностью харда,если я правильно понял смысл написанного. Когда вышел на блог разработчика ( если это правда) - из описания понял, что tool работает только с IDE и данных не трогает. В Вашем случае, конечно, с 700-ми Гб рисковать ,пробуя неизвестное ,слишком неразумно было бы.