BVG Group
 
Имя:  
Пароль:    
 
 
• Регистрация
• Забыли пароль? 
  РУС     ENG   на главную карта сайта написать письмо
 ооо "Смарт"
+7 (925), (495) 772-45-95
Москва, ул. Космонавта Волкова, дом 10, стр. 1, "CHALLENGER", оф.101.
Skype: ooo_smart   ICQ: 164937826    Написать в Whatsapp            контакты


ВОССТАНОВЛЕНИЕ ДАННЫХ
ВОССТАНОВЛЕНИЕ ДАННЫХ  
 
оборудование
для диагностики
и ремонта
 

 
 
 
 
?iaaen.Iao?eea
 
Top.Mail.Ru
 
 

Проблема совместимости дисков большой емкости при восстановлении данных 

© Олег Васильев, BVG Group, 04.11.2012

Введение
 

Недавно, к нам обратился пользователь, которому надо было скопировать данные с одного трёхтерабайтного накопителя на другой. Источник он подключил к плате HRT, а приёмник - через переходник USB3.0, после чего начал жаловаться, что HRT DRE не поддерживает четырёхкилобайтные сектора. Дальнейшие разбирательства, показали, что не всё в этом вопросе просто. И возможно, результаты этих разбирательств будут полезны другим читателям.

Немного истории
 

Начнём, пожалуй, издалека. Немного пофилософствуем на тему, что же это такое - сектор диска? Давным-давно, когда диски были большими (в смысле физического размера, а не емкости), на них наносились настоящие полноценные сектора. Это делалось при форматировании диска. Только не тем форматированием, которое делает Windows (чисто размечает файловую систему)... Нет! Тогда не существовало быстрого формата. Тогда головка должна была прописать каждую дорожку. И для каждого сектора прописывалась адресная метка (которую можно было легко отличить от простых данных, так как она записывалась с нарушением правил кодирования), затем - шёл заголовок сектора, в котором прописывалась информация о дорожке и номере сектора, а уже затем шли данные, которые завершались или полем CRC, или ECC. Формат сектора для дисковода рассмотрен на рисунке ниже (для жёсткого диска всё чуть сложнее)

Соответственно, при чтении привод должен был сначала спозиционироваться на дорожку, а затем начать ожидание адресной метки. Найдя её, он должен был считать заголовок. Совпал - тогда читать или писать данные. Не совпал - ждать следующую адресную метку. Дисководы, кстати - это как ящерицы, уцелевшие после динозавров. Они до сих пор так делают (их более крупные собратья, которых возили на тележках, давно переделаны в телевизионные антенны).

Шло время, у приводов исчез шаговый двигатель. Появились звуковая катушка и сервометки. Но адресные метки ещё существовали, о чём свидетельствует бит ошибки AMNF у IDE накопителей - Address Mark Not Found. Затем была придумана технология ID-LESS, которая полностью изменила подход к понятию "Сектор".

Всё стало очень просто - у диска есть сервометки. Каждую сервометку можно точно идентифицировать. Зачем нам тратить поверхность под какие-то маркеры секторов, если сектора можно привязать к сервометкам? Соответственно, у нас появляется больше места для данных пользователя (раньше это место съедалось адресной информацией). Поэтому теперь накопитель пользуется таблицей ID-LESS формата (для каждого сектора указано после какой сервометки и с каким отступом от неё он размещён). Но прежде, чем рассуждать дальше, давайте немного поэкспериментируем. Возьмём накопитель Western Digital семейства BB (у более новых сменилась команда и результат стал менее нагляден) и попробуем преобразовать логические сектора в физические. Обычно, одному логическому сектору соответствует одна запись о физических координатах

Но вот сектор, который распадается на два

Как такое может получиться? А вот как: со времён появления ID-LESS формата, на передний план вышло такое понятие, как WEDGE (перевод "Клин" мне не нравится, давайте будем называть его "Сервосектор"). Сервосектор - это область данных, расположенная между двумя сервометками. Причём если в привычном нам зонном распределении, число секторов уменьшается с увеличением номера зоны:

то число сервосекторов на дорожку остаётся неизменным. Сами сервометки размещены примерно так:

И вообще-то, аппаратура накопителя считывает всегда один сервосектор, а уже затем - "выковыривает" из считанного буфера непосредственно сектор с данными. И само собой, размер сектора данных не кратен размеру сервосектора (и вообще, соотношение переменное - чем больше номер зоны, тем меньше секторов влезает в сервосектор). И может получиться вот такая картина:

Что делать с местом, куда могла бы влезть часть физического сектора 2? Оставить пустым? Очень хорошо, мы только избавились от адресных маркеров в пользу данных пользователя, а теперь будем оставлять пустое место! Ну уж нет! Лучше пусть часть сектора попадёт в один сервосектор, часть - в другой. Отсюда и появились две записи, соответствующих одному физическому сектору, с которых мы начали.

Зная обо всём этом, мы теперь с лёгкостью вычислим "переходные" сектора и на современных накопителях Western Digital. Просто там отмечается первый из них, который упирается в сервометку. Поэтому у него размер будет не полный (на рисунке ниже - полный 0x200 байт, а у переходного - всего 0x8A байт. Зато видно, что он является последним для сервосектора номер 0x28.

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

Время шло, плотность росла. Рос и размер сервосектора, а значит - объём данных, считываемых за один проход. Нельзя точно сказать, что было тому причиной. То ли выросшие таблицы, то ли ещё что (производители дисков не очень-то публикуют истинные сведения, считая их конфиденциальными), но со временем появилось тяготение к увеличению размера физического сектора. И сейчас почти все производители делают его равным 4 килобайтам. И в целом - из сказанного выше ясно, что на самом деле, просто распухшие сервосектора теперь делят не на бешеное количество кусочков по 512 байт, а на меньшее число крупных кусков по 4096 байт.

Размер имеет значение
 

Теперь посмотрим на другой аспект. Это размер разрядной сетки. Не многие, наверное, помнят про проблемы, связанные с накопителями, ёмкостью больше 512 мегабайт, затем - 2 гигабайт, затем - 32 гигабайт. Все эти лимиты были связаны с трансляцией CHS, принятой на первых дисках, так и укоренившейся в BIOS компьютеров тех времён. Трансляция LBA устранила все эти проблемы, и пользователи уверенно глядели в будущее, пока ёмкость не упёрлась в 128 гигабайт. А что такое 128 гигабайт?


128*1024*1024*1024 = 137438953472 байт.

1 сектор равен 512 байтам, то есть это 137438953472/512=268435456 секторов.

Чтобы представить это число, надо 29 бит (проверьте, шестнадцатеричное число 0x10000000 или двоичное 10000000000000000000000000000, посчитайте биты пальцем), а трансляция LBA давала только 28. Тут на выручку пришла трансляция LBA48. Она сняла проблему, и пока что для ATA накопителей всё хорошо. Правда, в Windows 2000 SP3/SP4 и Windows XP с первым пакетом обновления, чтобы включить LBA48, требовалось вписать специальный ключ в реестр, но это всё в прошлом. XP SP2 уже не требует этого ключа. А уж Windows Vista и Windows 7 - и подавно. Ура? Не совсем.

Кроме стандарта ATA есть ещё и стандарт SCSI. И в этом стандарте долгое время господствовал размер LBA, равный 32 битам. Только относительно недавно появились команды, поддерживающие 64 битную адресацию, да вот беда - не все драйвера знают о них. Итак. Что такое 32 бита? Это 0x100000000 секторов. То есть, в десятичном виде 4294967296. Умножаем на 512 (размер сектора), получаем 2199023255552 байт. Трижды делим на 1024 (откидываем гигабайты, мегабайты, килобайты), получаем 2048. Итого, LBA32 адресует 2 терабайта. Вспоминаем начало статьи - всё началось с проблем у человека, когда он взял в руки трёхтерабайтный накопитель.

"Позвольте", воскликнет читатель, "Но при чём тут SCSI, SAS и прочая дорогая техника? У меня обычная USB коробочка, да и в начале статьи речь шла именно о USB3". А при том, что накопители, подключённые к порту USB, логически работают по протоколу Mass Storage Device. А этот протокол максимально "маскируется" под SCSI. По крайней мере, и коды и формат команд, там взяты именно от SCSI. И, соответственно, размер LBA - тоже долгое время был равен 32 битам.

Первые условности
 

Итак. Начнём с того, что некоторые переходники SATA-USB просто не поддерживают LBA, больше 32 бит, и не работают с дисками, больше 2 терабайт. Их мы не рассматриваем, и через них приёмники при восстановлении данных не подключаем. Оставим такие переходники для "файлопомоек" малого объёма.

Трёхтерабайтные диски в таких переходниках будут определяться, как 750 гигабайтные. Возьмём типичный размер в LBA трёхтерабайтного диска 5860533168, переведём в шестнадцатеричную систему - 0x15D50A3B0. Для записи этого числа надо 33 разряда. Любой 32 разрядный переходник потеряет старшую единицу (это же сделает и любая программа для компьютера, оперирующая 32 битными LBA), получаем 0x5D50A3B0. Переводим в десятичный вид - 1565565872 секторов. Умножаем на 512 (размер сектора) - 801569726464 байт. Трижды делим на 1024 (откидывая кило, мега, гига) - получаем 746. Вот как раз и есть эти 750 (примерно) гигабайт. Никаких чудес, простая потеря старшего бита.

Следующий класс переходников, знает о современных SCSI командах. Они, в ответ на классическую команду READ CAPACITY (10) с кодом 25h, в полном соответствии со стандартом, выдадут размер 0xFFFFFFFF LBA, указав верный размер сектора 512 байт. А, соответственно, полный объём выдадут в ответ на команду READ CAPACITY (16). Если вдруг кто-то с ней не знаком, вот её формат

А вот - формат ответа накопителя

То есть, всё то же самое, только размер LBA увеличен.

Соответственно, для чтения и записи используются 16 битные варианты команд READ и WRITE

Вот формат команды чтения

А вот - записи

Такие переходники не вызывают никаких проблем, если через них подключить накопитель-приёмник для HRT DRE, так как они полностью копируют поведение аналогичных SATA накопителей. То есть, размер сектора и количество LBA у USB накопителя будет таким же, как и у стоящего за переходником SATA накопителя. Но при работе с Windows XP без специальных драйверов (по крайней мере, с ранними пакетами обновления), могут возникнуть проблемы. Ну, просто потому, что драйверы не знали о существовании таких команд. Они увидят только 2 терабайта, и будут работать только с ними.

И, наконец, существует третий вид переходников, которые пытаются решить проблему совместимости со старыми драйверами, не "вылетая" при этом за размер 32 битного LBA. А делают они это очень просто. Помните, при вычислении разрядности, я умножал число 0x100000000 на 512? А если мы заявим, что размер сектора у нас равен 4096? Тогда уже мы можем обслужить 17592186044416байт, то есть, 16 терабайт. Проблема отодвинута в сторону! А просто когда по USB нас попросят считать один сектор с LBA номер N, в накопитель уйдёт задание считать 8 секторов с LBA = 8 * N. Вот и всё. Windows будет прекрасно работать, так как она понимает любой размер сектора. А все масштабирования на себя берёт чип переходника.

Но вот в качестве приёмника для классического HRT DRE такой переходник в корне не годится, так как размер сектора источника и приёмника будут отличаться, хотя физически это могут быть накопители одной и той же модели.

Давайте сделаем вывод из раздела. Сектор, равный 4 килобайтам в данном случае - это искусственное решение, сделанное разработчиками USB переходников чисто для того, чтобы обойти проблемы разрядной сетки LBA в классических SCSI командах. Это - случайное совпадение с 4 килобайтным сектором, описанным выше, не имеющее ничего общего по физической сути. За USB переходником вполне может стоять накопитель, который никому ничего не говорил о своей четырёхкилобайтности (об этом - ниже). Просто переходник заметил, что он не уложится в 32 битный LBA, и волевым решением изменил размер сектора, производя внутренний пересчёт.

Если отформатировать большой накопитель в Windows, а затем подключить его через такой переходник, то скорее всего, Windows не увидит данных. Чисто потому, что адресация при прямом подключении была на уровне 512 байтных секторов, а при подключении через переходник - на уровне секторов 4К.

Тем не менее, ознакомившись с таким подходом, мы переделали подсистему записи в HRT DRE. В принципе, теперь при несовпадении размера сектора, комплекс сам производит перемасштабирование. То есть, если скопировать данные с диска 512Б на 4К, а затем - вытащить диск из переходника и вставить в компьютер - данные будут видны. До вытаскивания - нет. Потому, что размер сектора не тот... И с этим бороться нельзя.

Совместимость, совместимость и ещё раз совместимость
 

Но вернёмся к накопителям, у которых размер физического сектора равен 4 килобайтам. Думаете, у них и логический сектор стал таким же? Как бы не так! То ли из соображений, что некоторые программы могут сойти с ума, то ли ещё по каким причинам, но размер логического сектора как был равен 512 байтам, так до сих пор пока и остался равен им. Размер сектора можно определить, анализируя дамп команды ECh, давайте посмотрим фрагмент документации

Давайте разберёмся, что здесь написано. Во-первых, если бит 12 равен нулю, то размер логического сектора равен 512 байт (256 слов), и ни о чём думать не надо. Если он равен 1, то число слов (не байт!!!) на сектор берётся из слов 117 и 118. И оно может быть удивительным. Например, в стандарте ATA/ATAPI говорится про 528 байтные сектора.

Дальше, бит 13. Если он равен 1, то мы можем выяснить размер физического сектора. Берём биты 3..0, дальше возводим двойку в эту степень - получаем число логических секторов, умещающихся в один физический. То есть, если логический сектор равен 512 байт, а физический - 4 килобайта, разница в 8 раз будет кодироваться числом 3 (23=8).

Если длина логического сектора для нас жизненно необходима, то зачем понадобилось выяснять размер физического сектора? А для быстродействия. Допустим, у нас физический сектор равен 4 килобайта, и мы хотим записать данные с LBA=16 и длиной 8 логических секторов. Это полностью накрывает физический сектор (и LBA и длина кратны восьми). Поэтому необходимо и достаточно, просто записать данные. А если мы хотим записать только 2 сектора с LBA... Да пусть те же 16, то всё сложнее. Накопитель должен считать физический сектор в память, обновить только его фрагмент, длиной 1024 байта, после чего - записать назад.

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

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

Давайте рассмотрим, как показывает сведения о размере сектора комплекс HRT, доработанный с учётом новых веяний

Вот старый добрый накопитель:

А вот - накопитель с четырёхкилобайтным физическим и обычным логическим сектором:

Нестандартный логический сектор для ATA накопителей нам пока не попадался.

Совместимость от Apple
 

Если вынуть накопитель Toshiba из плеера iPod и попробовать считать его, то будет очень интересный эффект. Дело в том, что там размер физического сектора равен 2 килобайта, а размер логического - 512 байт. Однако, обращаться можно только к блокам, "наложенным" на физический сектор. Рассмотрим примеры.

То есть, номер LBA и число секторов должны быть кратным четырём (как раз 2 килобайта)

Берём точно такой же диск, но не из плеера, а с рынка - никаких подобных проблем не возникает. Однако, это показывает, что посекторное вычитывание иногда приходится вести также для целого физического сектора. Потому что поштучно просто не отдаст накопитель. Это также учтено в последней версии HRT DRE.

Выводом из этого раздела, будет тот факт, что совместимость дисков, предназначенных для специфического применения, вполне может быть лишь частичной. Вроде, логический сектор и 512 байт (наверняка иначе пришлось бы переписывать исходный текст поддержки FAT), а при отсутствии кратности - даёт ошибку. Хотя, может там и маркетинг виноват. То ли чтобы диски не воровали с завода и не продавали, то ли наоборот, чтобы произвольные диски не вставляли, увеличивая при этом объём. Тем не менее, при восстановлении данных, нам это надо учитывать. Иначе посекторное вычитывание не пройдёт.

Заводская совместимость
 

Ну, и наконец, производители должны думать о том, как тестировать накопители. Результаты тестирования при этом помещаются в служебную область. При этом, кто только к служебной области ни обращается! В первую очередь, конечно же, программы для IBM PC. По сети гуляют разные программки для накопителей Quantum или, скажем, Westrn Digital. Дальше, к ней же обращаются разные специализированные приборы, применяемые на заводах. Автору довелось поглядеть на прибор для накопителей Toshiba. Опять же, Selfscan. Он тоже пишет в служебную область. А исполняется он процессором накопителя при заводском тестировании. Ну, и наконец, сами накопители во время нормальной работы... SMART, например, журналы записывает. G-LIST обновляется. Возможно - ещё какие-то подсистемы что-то делают. Опять же, оверлеи необходимо считывать. В общем, к служебной области обращается просто бешеное количество различных программ, исполняемых на совершенно разных платформах, исходные тексты которых "весят" многие мегабайты. И достаточно сложно взять и переделать всё, что используется в техпроцессе и процессе жизни накопителя с сектора 512 байт на сектор 4К.

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

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

Заключение
 

Итак. Мы познакомились с причинами появления больших секторов. Это может быть из-за повышения плотности записи, но может - и чисто для того, чтобы обойти переполнение разрядной сетки (при том, что целевая ОС не понимает новых 64 битных команд). Мы выяснили, что во втором случае, один и тот же диск, подключённый напрямую к SATA и через USB переходник, будет рассматриваться операционной системой совершенно по-разному. И файловая система будет увидена только там, где он был отформатирован.

Из всего этого, стало ясно, почему прежние версии HRT DRE не копировали трёхтерабайтные диски, когда в качестве приёмника используется пересчитывающий USB переходник. Мы выяснили, что проблема решается копированием на "правильный" переходник, который не масштабирует размер сектора.

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

Попутно, мы выяснили, как трёхтерабайтные диски превращаются в 750 гигабайтные. Просто программа (исполняющаяся в компьютере или в переходнике) не анализирует больше, чем 32 бита, 3 теребайта требуют уже 33 бита. Потеря старшего бита и порождает число 750Г.

Эти знания, надеюсь, помогут вам избежать ошибок при восстановлении данных с дисков большого объёма.

eng 
рус
на главную |  наши цены |  наши дилеры |  новости | 
информация по восстановлению данных |  карта сайта 
© 2006-2022 BVG Group
e-mail: office@bvg-group.ru 
   Компания BVG Group - профессиональное восстановление данных с различных цифровых носителей.