Маркетинговые штучки: сноб-потребитель и слишком большой и быстрый HDD.
реклама
Маркетинговые штучки: сноб-потребитель и слишком большой и быстрый HDD.
В этой серии заметок мы поговорим о неутомимой борьбе сноба-потребителя с такими энергонезависимыми накопителями информации, как жесткие диски. Как обычно, пойдем в обход, используя много вводного материала.
Часть первая.
"Произошла неустранимая системная ошибка: ваш жесткий диск слишком большой и быстрый, система была остановлена."
сообщение операционной системы.
А начнем мы с такой на первый взгляд смешной проблеме 2012 года, как слишком большие и слишком быстрые жесткие диски, при работе с которыми у современных улучшенных операционных систем возникают трудности.
Содержание.
1. Как расширять MBR.
2. Почему плохо работать с логическими секторами по 512 байт поверх физических секторов по 4Кбайт?
3. Почему хороши HDD диски большого объема?
1. Как расширять MBR.
Когда появился жесткий диск, то для совместимости с программами его стали представлять как один или более гибких дисков. Каждый виртуальный гибкий диск назвали разделом, а размещение разделов на жестком диске хранит специальная таблица — таблица разделов. Обычно эта таблица внесистемная, т.е. ее формат известен и Майкрософт и Unix.
Для того, чтобы операционная система, ориентированная на гибкий диск, смогла загрузиться и с жесткого диска, существует специальная загрузочная программа, которая расширяет сервис BIOS (который в то время нельзя было перепрошивать) для поддержки конкретной операционной системы. Обычно эта программа внесистемная, т.е. почти не зависит от типа операционной системы и загрузочная программа от Майкрософт прекрасно загрузит раздел с Unix и наоборот.
Таблица разделов и внесистемный загрузчик вместе образуют загрузочную запись - MBR, формат которой ограничен тем, что MBR используется BIOS при загрузке операционной системы, т.е. BIOS загружает MBR и передает ей управление дальнейшей загрузкой вполне определенным образом, что и является ограничителем, фактически загрузчик MBR это часть BIOS, вынесенная на жесткий диск. В целях совместимости программ, эта MBR и сохранилась до наших дней такой странной, какой мы ее видим сейчас.
Отметим, что BIOS ничего не знает ни о формате MBR, ни о разделах ни о методах их описания, BIOS только загружает эту MBR в память и передает ей управление определенным образом, после чего дисковое пространство можно распределять и описывать произвольным образом. Это значит, что MBR может быть абсолютно любой (совместимой практически с любой разметкой диска, если только не приняты меры по искусственному введению такой несовместимости), но мы под MBR в этом тексте будем понимать только совместимую, традиционную MBR.
Для 16 битных BIOS-based приложений есть CHS формат MBR (условно назовем его MBR16), который адресует сектора на дисках с прямым указанием цилиндра/головки/сектора на дорожке, фактически это расширение на жесткий диск формата обращения к гибкому диску. Где-то с 1995 года для всех продаваемых IDE HDD формат CHS, о котором они сообщают, стал логическим, поскольку диски имели разное число секторов на разных дорожках и даже могли скрывать поврежденные сектора от внешнего мира.
Сохранение логической CHS адресации у HDD позволило бы совмещаться с программами, ориентированным на 16 бит BIOS и контроллерами IDE на матплате, однако, контроллер IDE на матплате имел ограничения на параметры CHS (0-65535/0-15/0-63), в результате чего HDD диски имели логическую структуру CHS, которая была несовместима с ограничениями на CHS для 16 бит BIOS (0-1023/0-255/1-63) и с ограничениями на CHS для MSDOS (0-1023/0-254/1-63) , но при этом и не являлась точной геометрией диска.
Любимое дело всякого интерфейса это введение специального смысла для числовых значений параметров, любимые специальные числа это 0 (все биты выключены) и -1 (все биты включены), первое должно символизировать вселенскую пустоту в философском смысле, а второе — страшную, неисправимую ошибку. Подобное резервирование приводит к некратным степени 2 максимальным значениям и к трудностям с преобразованиями. Обструкции в данном случае подверглись число секторов (63) и головок (255).
Преобразование логической структуры CHS от IDE HDD в логическую структуру CHS для BIOS должно было выполняться силами IDE-части BIOS, старые BIOS этого не умели, а новые в то время предлагали адресовать сектора на диске в режимах Normal/Large/LBA.
Если в каком-либо BIOS на каком-либо параметре, например выбора режима Normal/Large/LBA нажать F1, то система помощи BIOS немедленно проинформирует вас о том, что это параметр BIOS, где можно выбрать между Normal/Large/LBA.
В режиме Normal никакого преобразования не выполнялось, это режим совместимости со старыми BIOS, поэтому из-за совместно применяемых ограничений 16 бит BIOS весь диск был недоступен для 16 битных BIOS-based приложений, обычно дорожки с номерами более 1023 были недосягаемы, потому как число головок, о которых рапортовали HDD, всегда было менее 16, а число секторов всегда было равно 63.
Режим Large это вариант действий «давайте немного улучшим CHS», я ни разу не использовал этот режим, но в этом режиме увеличивалось число виртуальных головок, которые доступны программе через 16 бит BIOS, поэтому больше логических дорожек диска, о которых рапортует HDD, было доступно. Данный режим преобразования номеров не очень стандартен и диск, размеченный под одним BIOS может быть несовместим с BIOS другого компьютера.
Только отметим на будущее саму идею введения способа несовместимой разбивки.
Правильный режим трансляции это режим LBA, когда все сектора HDD последовательно пронумеровали, и для преобразования из любой CHS адресации в LBA ввели простое правило перебора секторов справа налево по полям CHS:
|
|
|
---|---|---|
|
|
|
реклама |
|
|
|
|
|
|
|
реклама |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
реклама |
|
|
|
Во времена, когда делали 16-бит BIOS, диски имели размер 360Кбайт и никто не думал о том, что размер диска может быть безграничным. Теоретически, три числа по 16 бит для CHS дают 48 бит, но из-за исторических причин их размер ограничен в 1024/255/63 = 16450560 секторов (неполные 24 бита). При размере сектора в 512 байт это 7.8Гбайт. Это огромная для 1980 года величина к 2000 году была превышена, появились диски в 10, 12, 16 Гбайт.
Поскольку в то время разговор подходил к 64-битным процессорам, справедливо полагали, что участка диска размером 7.8Гбайт для старых 16-бит BIOS-based приложений будет предостаточно. Для 32-битных систем, которые используют расширения BIOS и собственные драйвера, были доступны реальные значения CHS, которые рапортуются HDD, но проблема в том, что 16-ти байтные записи о разделах в MBR имеют формат, который нужен чтобы прямо скормить эти значения в 16-бит BIOS:
начало раздела описывают три байта:
01h |
1 |
Начало раздела — головка |
02h |
1 |
Начало раздела — сектор (биты 0—5), дорожка (биты 6, 7) |
03h |
1 |
Начало раздела — дорожка (старшие биты 8, 9 хранятся в байте номера сектора) |
конец раздела описывают три байта:
05h |
1 |
Конец раздела — головка |
06h |
1 |
Конец раздела — сектор (биты 0—5), дорожка (биты 6, 7) |
07h |
1 |
Конец раздела — дорожка (старшие биты 8, 9 хранятся в байте номера сектора) |
Поэтому даже для 32 битных систем в формате MBR было бы невозможно разметить диск, который был более 7.8 Гбайт. Однако мы все пользуемся дисками большего размера, которые удается разметить в формате MBR, как объяснить этот парадокс? Очень просто, в 16 байтном массиве, который был отведен в MBR16 для описания раздела, никак не использовалось целых восемь байт. Не долго думая, эти 8 байт были отведены под описание рездела в стиле LBA:
начало раздела описывают четыре байта:
08h |
4 |
Смещение первого сектора |
конец раздела описывают четыре байта:
0Ch |
4 |
Количество секторов раздела |
Возможно было время, когда эти байты в записи раздела MBR были просто зарезервированы или имели иное значение, потому что если параметр «количество секторов раздела», который дублирует две записи в формате CHS еще как-то можно оправдать необходимостью отображения размера раздела без операции вычитания, то параметр «смещение первого сектора» точно лишний, поскольку для этого есть прямая запись в формате CHS. Наличие дублированных параметров всегда порождает проблемы, когда такие параметры начинают не совпадать друг с другом и при этом корректирующую функцию они не выполняют.
Как же быть с CHS параметрами в MBR, которые физически не могут указать за пределы 7.8Гбайт? Никак. Эти 6 байт просто не используются, храня магические значения 1023/254/63 которые для приложений, ориентированных на CHS, адресуют клочок диска в пределах 7.8Гбайт. Те, кто видел отчеты partition magic о разделах, отмечал его предупреждения, что реальные значения параметра того или иного раздела указаны в полях LBA.
Хорош этот метод или плох? Хорош, поскольку MBR совместима с предыдущими версиями софта. Плох, тем что 6 байт из 16 в записи о разделе MBR расходуются на совместимость, т.е. не используются.
А вообще, какие задачи стояли при улучшении структуры MBR: а) изолировать часть диска, недоступного для старых программ от их внимания; б) иметь возможность провести границу старое/новое по любому адресу и в переделах 7.8Гбайт.
Если бы не второе требование, то вместо модернизации MBR16, после части диска, размеченного через MBR, можно было бы разместить таблицу нового формата. Более того, вынос раздела, доступного только для более надежного 32 битного кода за границу 7.8Гбайт рекомендовалось в переходный период, когда на одном диске жили MS-DOS и Windows XP.
Но пошли другим путем. Описание раздела в MBR имеет поле, которое указывает на тип раздела, т.е. на тип операционной системы, которая установлена в этом разделе:
04h |
1 |
Код типа раздела |
Традиционная MBR содержит всего 4 поля по 16 байт для описания разделов, т.е. только 4 виртуальных гибких диска предполагалось подключать одновременно. Но скоро выяснилось, что этого недостаточно, поэтому для размещения более чем четырех разделов применяется расширенный раздел, который имеет структуру подобную логическому отдельному жесткому диску: в начале расширенного раздела идет аналог MBR – EBR, таблица традиционного EBR содержит описание одного раздела в формате MBR и ссылку на следующий EBR, если есть еще разделы внутри расширенного.
Традиционный загрузчик MBR не умеет искать загрузочные разделы, перелистывая расширенный раздел, но, например, загрузчик grub может загрузить операционную систему из расширенного раздела, если сама операционная система допускает такую загрузку.
Код типа с номером 0Fh указывает на расширенный раздел, который описывает данные своих разделов в полях LBA. Для 16 битных BIOS-based приложений формат этого раздела неизвестен и не нужен, поскольку для них есть свой расширенный раздел с номером 05h, который описывает свои разделы в полях CHS.
Четыре байта LBA в традиционой MBR (назовем это MBR32) позволяют адресовать до 2^32 секторов. При размере сектора в 512 байт это 2Тбайт диски, что еще пару лет назад было недостижимой величиной на реально существующих десктопах. Таким образом, предел диска в 2Тбайта связан с тем, что традиционая MBR использует LBA32.
В общем эта мысль очень простая и так подробно я расписывал только для того, чтобы поговорить о модификациях MBR, но попробуйте из текстов формата A4, которые валяются в сети и предназначены для описания проблемы предела диска в 2Тбайт это понять.
В наше время HDD диски могут быть более 2Тбайт, а интерфейс с диском допускает обмен в формате LBA48. Как описать разделы такого диска с помощью MBR?
Интересно отметить что делают в такой критический момент производители HDD. Удар пришелся на размер сектора, который увеличили с 512 байт до 4К. Этот шаг не может рассматриваться как борьба с пределом дисков для MBR32, как было ими иногда заявлено. Первая проблема здесь в том, что не каждая операционная система может адресовать сектора произвольного размера, т.е. теряется совместимость. Вторая проблема в том, что увеличить емкость в 8 раз это мало, поскольку предельное значение диска с 2Тбайт переносится на 16Тбайт, а RAID 0 массив из 4-х дисков по 4Тбайта уже исчерпывает резерв.
Ясно, что операционные системы, которые понимают только MBR32 или файловые системы, которые не могут ссылаться более чем на 2^32 секторов размером 512 байт никогда не смогут адресовать диски размером более 2Тбайт. Для других систем не требуется ничего — ни UEFI BIOS, ни секторов по 4К, ни чего-то еще грандиозного, кроме резервирования очередного номера для расширенного раздела, параметры логических разделов в котором описываются 12 байтами формата LBA48, а не 8 байтами LBA32.
Обновления совершенно косметические, не могут влиять на загрузку ОС и т.д. и касаются только конкретной ОС, только ее способности понимать расширения MBR48.
Чтобы не быть голословным, предлагаю отличный готовый вариант для записи информации о разделах в гипотетической MBR48, которая не боится дисков более 2Тбайт, на изготовление которого у меня ушло несколько минут (много меньше, чем на оформление этого текста).
Резервируем в добавок к номерам 05h и 0Fh новый номер типа раздела, например, номер 0EFh для указания на расширенный раздел MBR48. В пределах этого нового расширенного раздела (правильно описывающего диск в правилах для MBR16/32), формат которого для систем ориентированных на MBR16/32 неизвестен и не нужен, уже можно размещать EBR48, записи о разделах в которых оперируют параметрами LBA48.
А вот формат 16 байтной записи о разделе с параметрами LBA48:
старший бит этого поля зарезервирован в MBR для указания раздела, выбранного для загрузки:
00h |
1 |
Признак активности раздела |
не используется в MBR48:
01h |
1 |
Не используется |
старшие два байта указания на начало раздела :
02h |
2 |
Смещение первого сектора LBA48, байты 5-4, младший байт первый |
поле «код типа раздела» для MBR48:
04h |
1 |
Код типа раздела MBR48 |
не используется в MBR48:
|
1 |
Не используется |
старшие два байта указания на конец раздела :
06h |
2 |
Количество секторов раздела LBA48, байты 5-4, младший байт первый |
младшие четыре байта начала раздела:
08h |
4 |
Смещение первого сектора LBA48, байты 3-0 |
младшие четыре байта конца раздела:
0Ch |
4 |
Количество секторов раздела LBA48, байты 3-0 |
Видно, что все творчество сводится к тому, что поля CHS в записи о разделе от MBR16 используются для хранения значений LBA48. Такая запись о разделе может появиться только в расширенном разделе MBR48. Первый EBR48 такого раздела должен содержать запись (поле «код типа раздела» для MBR48 указывает на нее), которая описывает сам расширенный раздел в параметрах LBA48 (размер диска, который выделен под этот расширенный раздел), поскольку данные об этом разделе в формате CHS и LBA32 некорректны.
Вывод:
Учитывая тот факт, что до 2010 года практически не выпускались матплаты с UEFI BIOS, а эти матплаты еще очень активно используются (можно считать, что матплаты до сокета 1155 и am3+ не имеют UEFI BIOS), в приказном порядке отказаться от модификации MBR32 это спекулятивная акция, направленная на искусственное создание несовместимости. В переходный период операционная система должна поддержать две модели распределения дискового пространства — старая, на основе традиционного BIOS и расширения MBR до LBA48; и новая, на базе UEFI BIOS.
2. Почему плохо работать с логическими секторами по 512 байт поверх физических секторов по 4Кбайт?
Потому что операция записи 512 байт превращается в операцию чтения 4К — модификации 512 байт из них — записи 4К на диск. Скорость может упасть более чем в два раза. Для операций чтения нет разницы.
Разделы в MBR не требуют выравнивания по границе 4К, если файловая система в этом разделе позволяет резервировать произвольное число секторов до области хранения данных (выравнивание производится манипулированием числом резервных секторов при форматировании файловой системы) и не рассматривает данные через кластеры кратные 4К (выравнивание не поможет), поскольку для MBR есть определенные традиции по размещению границ разделов по отношению к числам CHS, а для файловых систем таких традиций нет.
В общем и целом, гарантию быстрой работы с секторами не равными 512байт может дать только конкретная файловая система (NTFS, FAT и т.п.), которая рассчитана производителем на размер сектора не равный 512 байт (4K ready) и при форматировании которой все ее важные для скорости структуры выравниваются по границам физических секторов.
3. Почему хороши HDD диски большого объема?
Потому что скорость доступа к диску зависит от цилиндра, т.е. от LBA номера сектора, например, скорость доступа для секторов с номерами менее 5% от числа всех секторов на диске может быть в 2 раза быстрее, чем для секторов с номерами после 95%.
Поэтому при объединении в RAID 0 массив дисков, есть смысл разделять полученный массив на разделы по скорости. Обычно чем больше объем диска (число секторов на нем), тем больше секторов в абсолютном выражении попадает в скоростной раздел. Конкретные границы зависят от моделей HDD, которые объединяются в RAID 0 и от требований к сохранению максимальной скорости. Для некоторых моделей и критерии 20% падения скорости граница разделов лежит на 50% от числа секторов.
Обсуждение этой заметки в форуме.
Создано: 27.08.12
Последний раз отредактировано: 27.08.12
реклама
Лента материалов
Соблюдение Правил конференции строго обязательно!
Флуд, флейм и оффтоп преследуются по всей строгости закона!
Комментарии, содержащие оскорбления, нецензурные выражения (в т.ч. замаскированный мат), экстремистские высказывания, рекламу и спам, удаляются независимо от содержимого, а к их авторам могут применяться меры вплоть до запрета написания комментариев и, в случае написания комментария через социальные сети, жалобы в администрацию данной сети.
Сейчас обсуждают