Ошибка чтения сектора

Собственно, маловероятно, что бы сектор был разрушен целиком. Чаще всего "сыплется" только какая-то его часть, а все остальные данные остаются неискаженными. Существуют контроллеры двух типов. Первые, обнаружив расхождение контрольной суммы считанного сектора, все же оставляют прочиненные данные в буфере, и позволяют их извлечь оттуда, проигнорировав ошибку чтения. Вторые либо очищают буфер, либо просто не сбрасывают внутренний кэш в результате чего все равно прочитать буфер невозможно. На практике обычно встречаются последнее. При этом сброс кеша можно инициировать серией запросов без считывания полученных данных. Кеш при этом переполняется, и наиболее старые данные будут вытолкнуты в буфер. Остается их только прочесть. Конечно, это крайне медленно, но, к сожалению, универсальной команды сброса кеша не существует. Разные разработчики реализуют это по-своему (впрочем, иногда это можно найти в документации на чипы, используемые в контролере). 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 бит (необходимо уточнить у конкретного производителя) и содержимое остальных пакетов, как правило, остается достоверным. Самое интересное, что зачастую сбойный пакет можно восстановить методом перебора! При этом можно даже рассчитать, сколько вариантов должно получиться. Учитывая хорошую степень "рассеяния" корректирующих кодов можно сказать, что не очень много. И таким образом можно восстановить казалось бы безнадежно испорченные сектора, а вместе с ними и файлы, расположенные "поверх" последних.