Зависимость трансляции LBA от физических параметров диска

В ряде задач по восстановлению файлов с поломанных винчестеров приходится сталкиваться с ситуацией, когда в результате повреждений поверхности под одной или нескольким головками в пакете, приходится читать доступные сектора по отдельным головкам, летящим над не поврежденными плоскостями. Иногда получается выудить структуру папок и подкаталогов с именами файлов, иногда нет, и приходится вычитывать по заголовкам. Но практически всегда при попытке построить прогноз по восстановлению и самое главное, по его результатам, мне приходится сталкиваться со сложностями объяснения заказчикам принципов построения трансляции в системе координат "физическая головка — логический сектор".

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

Итак, когда мы "открываем" содержимое жесткого диска в шестнадцатеричном редакторе, например в WinHEX, как физическое устройство, мы имеем возможность работать с накопителем на самом низком с точки зрения операционной и файловой систем уровне. На данном шаге нам доступен полный объем диска, с 0-го сектора, по последний, например HDD Samsung 2Tb HD204UI, не обрезанный по HPA, имеет максимально доступный, последний сектор LBA за номером 3 907 029 168.

Логический вид доступной поверхности диска

Далее, представляем себе логическую область диска в виде некоей линейки, где начало это 0 Lba а конец - 3 907 029 168 LBA. Если бы у этого жесткого диска была одна физическая головка и одна поверхность, то проблем с пониманием какой сектор какой физической головой читается не возникает, - все сектора читались бы одной единственной головкой.

Предположим, у нас некий винчестер, у которого Lba MAX 1 000 000 секторов, внутри одна пластина имеющая, само собой, две поверхности - верхнюю и нижнюю. И используются обе. Блок голов парный — две читающих головки. Особенность всех современных дисков в том, что транслятор строится не по принципу читаем половину по 1-й голове и вторую по 2-й, а чтение происходит кусками, часть по 1-й, часть по 2-й, следующий кусок по 1-й и опять, следующий за ним, по 2-й. Сделано так для того, чтобы избежать длинных перемещений актуатора, т.н. seek-ов, при эксплуатации диска в пользовательском режиме, что неизбежно сказалось бы на производительности в сторону замедления. Таким образом, если мы не имеем возможности вычитать сектора по одной из двух головок, мы формально прочитаем половину, от доступного. А фактически, будет вот такая картина, как на иллюстрации, где зеленым цветом помечены вычитанные блоки данных, по 1000 килобайт, а белым — не вычитанные. Как нетрудно догадаться, в описываемой ситуации все файлы с размером, большим блока (1000 килобайт) будут битыми, т.е. содержать не вычитанные области.

Построение трансляции на 2-х головом жестком диске

Более того, по закону вероятностей, учитывая тот факт что далеко не все все файлы на диске одного размера, обязательно будет ситуация когда даже файл меньшего, чем блок транслятора, размера будет начинаться за границей этого блока (и тогда начало будет не вычитанным а файл, соответственно, битым) или за границей блока заканчиваться.

Поэтому в нашей гипотетической ситуации с диском в миллион LBA и блоком трансляции 1000 килобайт, "под завязку" записанным данными, с двумя головами, если читать по одной, то не смотря на то, что математически будет вычитана половина секторов, целых файлов будет не половина, а меньше. Будут целыми только файлы не больше 1000 килобайт, которым повезло оказаться целиком внутри вычитанных блоков. И тут уж зависит от удачи. Может и так статься, что сектора прочитаны, а толку с них нет - или файлы были большие, или то что не нужно, сохранилось (системные файлы, ПО и т.п.) а то что нужно - "битое".

Дальше, вносим в наш пример такую переменную, как файловая система. У нее есть метафайлы, таблица размещения файлов, где описаны имена и адреса с прочей информацией, файлы могут быть фрагментированными и т.п. Когда на наш виртуальный пример накладывается ФС, то становится понятно, что итоговый результат будет печальнее. Часть таблицы размещения файлов будет порушена, и потеряются имена даже тех файлов, что лежали в пределах блоков трансляции. Если какой то файл был фрагментирован, то даже предположив чудо в виде ситуации, когда все фрагменты в вычитанных блоках, то не имея файловой записи с описанием адресов фрагментов и их размера, тоже ничего восстановить не получится.

На этом примере несложно самостоятельно уже представить, как выглядит картина у дисков с большим количеством голов. Например 4,6 или 8.

Построение трансляции на 4-х головом жестком диске с невычитанными данными по 3-й головке

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

Конечно, диски имеют шаг непрерывных блоков транслятора больше, чем в вышеприведенном примере. Десятки или даже сотни мегабайт. Но тем не менее общий принцип остается неизменным, и прогнозировать результат восстановления файлов в такой ситуации, как сохранение данных с запиленных дисков, очень непростое, если вообще возможное, занятие. Зачастую приходится читать, надеясь на лучшее, и готовясь к худшему :)