Use 64 bit lba или 4k block что лучше
Для работы с жестким диском его для начала необходимо как-то разметить, чтобы операционная система могла понять в какие области диска можно записывать информацию. Поскольку жесткие диски имеют большой объем, их пространство обычно разбивают на несколько частей — разделов диска. Каждому такому разделу может быть присвоена своя буква логического диска (для систем семейства Windows) и работать с ним можно, как будто это независимый диск в системе.
Способов разбиения дисков на разделы на сегодняшний день существует два. Первый способ — использовать MBR. Этот способ применялся еще чуть ли не с появления жестких дисков и работает с любыми операционными системами. Второй способ — использовать новую систему разметки — GPT. Этот способ поддерживается только современными операционными системами, поскольку он еще относительно молод.
Структура MBR
До недавнего времени структура MBR использовалась на всех персональных компьютерах для того, чтобы можно было разделить один большой физический жесткий диск (HDD) на несколько логических частей — разделы диска (partition). В настоящее время MBR активно вытесняется новой структурой разделения дисков на разделы — GPT (GUID Partition Table). Однако MBR используется еще довольно широко, так что посмотрим что она из себя представляет.
MBR всегда находится в первом секторе жесткого диска. При загрузке компьютера, BIOS считывает этот сектор с диска в память по адресу 0000:7C00h и передает ему управление.
Итак, первая секция структуры MBR — это секция с исполняемым кодом, который и будет руководить дальнейшей загрузкой. Размер этой секции может быть максимум 440 байт. Далее идут 4 байта, отведенные на идентификацию диска. В операционных системах, где идентификация не используется, это место может занимать исполняемый код. То же самое касается и последующих 2 байт.
Начиная со смещения 01BEh находится сама таблица разделов жесткого диска. Таблица состоит из 4 записей (по одной на каждый возможный раздел диска) размером 16 байт.
Структура записи для одного раздела:
Первым байтом в этой структуре является признак активности раздела. Этот признак определяет с какого раздела следует продолжить загрузку. Может быть только один активный раздел, иначе загрузка продолжена не будет.
Следующие три байта — это так называемые CHS-координаты первого сектора раздела.
По смещению 04h находится код типа раздела. Именно по этому типу можно определить что находится в данном разделе, какая файловая система на нем и т.п. Список зарезервированных типов разделов можно посмотреть, например, в википедии по ссылке Типы разделов.
После типа раздела идут 3 байта, определяющие CHS-координаты последнего сектора раздела.
CHS-координаты сектора расшифровываются как Cylinder Head Sector и соответственно обозначают номер цилиндра (дорожки), номер головки (поверхности) и номер сектора. Цилиндры и головки нумеруются с нуля, сектор нумеруется с единицы. Таким образом CHS=0/0/1 означает первый сектор на нулевом цилиндре на нулевой головке. Именно здесь находится сектор MBR.
Все разделы диска, за исключением первого, обычно начинаются с нулевой головки и первого сектора какого-либо цилиндра. То есть их адрес будет N/0/1. Первый раздел диска начинается с головки 1, то есть по адресу 0/1/1. Это все из-за того, что на нулевой головке место уже занято сектором MBR. Таким образом, между сектором MBR и началом первого раздела всегда есть дополнителььные неиспользуемые 62 сектора. Некоторые загрузчики ОС используют их для своих нужд.
Интересен формат хранения номера цилиндра и сектора в структуре записи раздела. Номер цилиндра и номер сектора делят между собой два байта, но не поровну, а как 10:6. То есть на номер сектора приходится младшие 6 бит младшего байта, что позволяет задавать номера секторов от 1 до 63. А на номер цилиндра отведено 10 бит — 8 бит старшего байта и оставшиеся 2 бита от младшего байта: «CCCCCCCC CCSSSSSS», причем в младшем байте находятся старшие биты номера цилиндра.
Проблема с CHS-координатами состоит в том, что с помощью такой записи можно адресовать максимум 8 Гб диска. В эпоху DOS это было приемлемо, однако довольно скоро этого перестало хватать. Для решения этой проблемы была разработана система адресации LBA (Logical Block Addressing), которая использовала плоскую 32-битную нумерацию секторов диска. Это позволило адресовать диски размером до 2Тб. Позже разрядность LBA увеличили до 48 бит, однако MBR эти изменения не затронули. В нем по-прежнему осталась 32-битная адресация секторов.
Итак, в настоящее время повсеместно используется LBA-адресация для секторов на диске и в структуре записи раздела адрес его первого сектора прописывается по смещению 08h, а размер раздела — по смещению 0Ch.
Для дисков размером до 8Гб (когда адресация по CHS еще возможна) поля структуры с CHS-координатами и LBA-адресации должны соответствовать друг другу по значению (корректно конвертироваться из одного формата в другой). У дисков размером более 8Гб значения всех трех байт CHS-координат должны быть равны FFh (для головки допускается также значение FEh).
В конце структуры MBR всегда находится сигнатура AA55h. Она в какой-то степени позволяет проверить, что сектор MBR не поврежден и содержит необходимые данные.
Расширенные разделы
Разделы, отмеченные в таблице типом 05h и 0Fh, это так называемые расширенные разделы. С их помощью можно создавать больше разделов на диске, чем это позволяет MBR. На самом деле расширенных разделов несколько больше, например есть разделы с типами C5h, 15h, 1Fh, 91h, 9Bh, 85h. В основном все эти типы разделов использовались в свое время различными операционными системами (такими как например OS/2, DR-DOS, FreeDOS) с одной и той же целью — увеличить количество разделов на диске. Однако со временем различные форматы отпали и остались только разделы с типами 05h и 0Fh. Единственное исключение — это тип 85h. Он до сих пор может использоваться в Linux для формирования второй цепочки логических дисков, скрытых от других операционных систем. Разделы с типом 05h используются для дисков менее 8Гб (где еще возможна адресация через CHS), а тип 0Fh используется для дисков больше 8Гб (и используется LBA-адресация).
В первом секторе расширенного раздела находится структура EBR (Extended Boot Record). Она во многом схожа со структурой MBR, но имеет следующие отличия:
- В EBR нет исполняемого кода. Некоторые загрузчики могут его туда записывать, но обычно это место заполнено нулями
- Сигнатуры диска и два неиспользуемых байта должны быть заполнены нулями
- В таблице разделов могут быть заполнены только две первых записи. Остальные две записи должны быть заполнены нулями
В отличие от MBR, где позволяется создавать не более четырёх разделов, структура EBR позволяет организовать список логических разделов, ограниченный лишь размером раздела-контейнера (того самого, который с типом 05h или 0Fh). Для организации такого списка используется следующий формат записей: первая запись в таблице разделов EBR указывает на логический раздел, связанный с данным EBR, а вторая запись указывает на следующий в списке раздел EBR. Если данный логический раздел является последним в списке, то вторая запись в таблице разделов EBR должна быть заполнена нулями.
Формат записей разделов в EBR аналогичен формату записи в структуре MBR, однако логически немного отличается.
Признак активности раздела для разделов структуры EBR всегда будет 0, так как загрузка осуществлялась только с основных разделов диска. Координаты CHS, с которых начинается раздел используются, если не задействована LBA-адресация, также как и в структуре MBR.
А вот поля, где в режиме LBA-адресации должны находиться номер начального сектора и количество секторов раздела, в структуре EBR используются несколько иначе.
Для первой записи таблицы разделов EBR в поле начального сектора раздела (смещение 08h) записывается расстояние в секторах между текущим сектором EBR и началом логического раздела, на который ссылается запись. В поле количества секторов раздела (смещение 0Ch) в этом случае пишется размер этого логического раздела в секторах.
Для второй записи таблицы разделов EBR в поле начального сектора раздела записывается расстояние между сектором самой первой EBR и сектором следующей EBR в списке. В поле количества секторов раздела в этом случае пишется размер области диска от сектора этой следующей структуры EBR и до конца логического раздела, относящегося к этой структуре.
Таким образом, первая запись таблицы разделов описывает как найти, и какой размер занимает текущий логический раздел, а вторая запись описывает как найти, и какой размер занимает следующий EBR в списке, вместе со своим разделом.
Структура GPT
В современных компьютерах на смену BIOS пришла новая спецификация UEFI, а вместе с ней и новое устройство разделов на жестком диске — GUID Partition Table (GPT). В этой структуре были учтены все недостатки и ограничения, накладываемые MBR, и разработана она была с большим запасом на будущее.
Кроме того, в отличие от MBR, структура GPT хранит на диске две своих копии, одну в начале диска, а другую в конце. Таким образом, в случае повреждения основной структуры, будет возможность восстановить ее из сохраненной копии.
Рассмотрим теперь устройство структуры GPT подробнее. Вся структура GPT на жестком диске состоит из 6 частей:
| LBA-адрес | Размер (секторов) | Назначение |
| LBA 0 | 1 | Защитный MBR-сектор |
| LBA 1 | 1 | Первичный GPT-заголовок |
| LBA 2 | 32 | Таблица разделов диска |
| LBA 34 | NN | Содержимое разделов диска |
| LBA -34 | 32 | Копия таблицы разделов диска |
| LBA -2 | 1 | Копия GPT-заголовка |
Защитный MBR-сектор
Первый сектор на диске (с адресом LBA 0) — это все тот же MBR-сектор. Он оставлен для совместимости со старым программным обеспечением и предназначен для защиты GPT-структуры от случайных повреждений при работе программ, которым про GPT ничего не известно. Для таких программ структура разделов будет выглядеть как один раздел, занимающий все место на жестком диске.
Структура этого сектора ничем не отличается от обычного сектора MBR. В его таблице разделов дожна быть создана единственная запись с типом раздела 0xEE. Раздел должен начинаться с адреса LBA 1 и иметь размер 0xFFFFFFFF. В полях для CHS-адресации раздел соответственно должен начинаться с адреса 0/0/2 (сектор 1 занят под саму MBR) и иметь конечный CHS-адрес FF/FF/FF. Признак активного раздела должен иметь значение 0 (неактивный).
При работе компьютера с UEFI, данный MBR-сектор просто игнорируется и никакой код в нем также не выполняется.
Первичный GPT-заголовок
Этот заголовочный сектор содержит в себе данные о всех LBA-адресах, использующихся для разметки диска на разделы.
Структура GPT-заголовка:
| Смещение (байт) | Размер поля (байт) | Пример заполнения | Название и описание поля |
| 0x00 | 8 байт | 45 46 49 20 50 41 52 54 | Сигнатура заголовка. Используется для идентификации всех EFI-совместимых GPT-заголовков. Должно содержать значение 45 46 49 20 50 41 52 54, что в виде текста расшифровывается как "EFI PART". |
| 0x08 | 4 байта | 00 00 01 00 | Версия формата заголовка (не спецификации UEFI). Сейчас используется версия заголовка 1.0 |
| 0x0C | 4 байта | 5C 00 00 00 | Размер заголовка GPT в байтах. Имеет значение 0x5C (92 байта) |
| 0x10 | 4 байта | 27 6D 9F C9 | Контрольная сумма GPT-заголовка (по адресам от 0x00 до 0x5C). Алгоритм контрольной суммы — CRC32. При подсчёте контрольной суммы начальное значение этого поля принимается равным нулю. |
| 0x14 | 4 байта | 00 00 00 00 | Зарезервировано. Должно иметь значение 0 |
| 0x18 | 8 байт | 01 00 00 00 00 00 00 00 | Адрес сектора, содержащего первичный GPT-заголовок. Всегда имеет значение LBA 1. |
| 0x20 | 8 байт | 37 C8 11 01 00 00 00 00 | Адрес сектора, содержащего копию GPT-заголовка. Всегда имеет значение адреса последнего сектора на диске. |
| 0x28 | 8 байт | 22 00 00 00 00 00 00 00 | Адрес сектора с которого начинаются разделы на диске. Иными словами — адрес первого раздела диска |
| 0x30 | 8 байт | 17 C8 11 01 00 00 00 00 | Адрес последнего сектора диска, отведенного под разделы |
| 0x38 | 16 байт | 00 A2 DA 98 9F 79 C0 01 A1 F4 04 62 2F D5 EC 6D | GUID диска. Содержит уникальный идентификатор, выданный диску и GPT-заголовку при разметке |
| 0x48 | 8 байт | 02 00 00 00 00 00 00 00 | Адрес начала таблицы разделов |
| 0x50 | 4 байта | 80 00 00 00 | Максимальное число разделов, которое может содержать таблица |
| 0x54 | 4 байта | 80 00 00 00 | Размер записи для раздела |
| 0x58 | 4 байта | 27 C3 F3 85 | Контрольная сумма таблицы разделов. Алгоритм контрольной суммы — CRC32 |
| 0x5C | 420 байт | 0 | Зарезервировано. Должно быть заполнено нулями |
Система UEFI проверяет корректность GPT-заголовка, используя контрольный суммы, вычисляемые по алгоритму CRC32. Если первичный заголовок поврежден, то проверяется контрольная сумма копии заголовка. Если контрольная сумма копии заголовка правильная, то эта копия используется для восстановления информации в первичном заголовке. Восстановление также происходит и в обратную сторону — если первичный заголовок корректный, а копия неверна, то копия восстанавливается по данным из первичного заголовка. Если же обе копии заголовка повреждены, то диск становится недоступным для работы.
У таблицы разделов дополнительно существует своя контрольная сумма, которая записывается в заголовке по смещению 0x58. При изменении данных в таблице разделов, эта сумма рассчитывается заново и обновляется в первичном заголовке и в его копии, а затем рассчитывается и обновляется контрольная сумма самих GPT-заголовков.
Таблица разделов диска
Следующей частью структуры GPT является собственно таблица разделов. В настоящее время операционные системы Windows и Linux используют одинаковый формат таблицы разделов — максимум 128 разделов, на каждую запись раздела выделяется по 128 байт, соответственно вся таблица разделов займет 128*128=16384 байт, или 32 сектора диска.
Диски, контроллеры, ОС и Advanced Format
Что такое Advanced Format
Увеличение размера сектора в 8 раз связано с необходимостью повышения эффективности размещения данных на современных дисках. Накладные расходы, связанные с 512-байтной разметкой, начинают мешать дальнейшему увеличению ёмкости HDD. Помимо служебных полей в каждом 512-байтном секторе присутствует поле с кодом коррекции ошибок (ECC) длиной в 50 байт. В 4096-байтном секторе длина ECC-поля составляет 100 байт. Общее эффективность хранения данных удалось улучшить примерно на 10%.
Естественно, поддержка нестандартных секторов требуется со стороны дисковых контроллеров и операционных систем. Для решения проблем с совместимостью был ввёден дополнительный стандарт 512E, который обозначает диски с физическим размером сектора 4096 байт, но при этом эмулирующие обычный размер сектора в 512 байт. Advanced Format диски без эмуляции обозначаются 4KN. Таким образом, сейчас существует три варианта разметки:
| Формат | Логический размер сектора | Физический размер сектора |
| | 512 байт | 512 байт |
| | 512 байт | 4096 байт (4КиБ) |
| | 4096 байт (4КиБ) | 4096 байт (4КиБ) |
Совместимость
Операционные системы
На первый взгляд кажется, что использование эмуляции 512-байтного сектора снимает все проблемы с совместимостью, но это не так. Во-первых, сразу же возникает проблема с производительностью. Что произойдет при записи блока размером 512 байт на диск с размером сектора 4096 байт (пусть и эмулирующий наличие секторов 512 байт)? Произойдёт классический процесс read-modify-write, вместо одной операции понадобится две: прочитать сектор 4096 байт, поменять в нём 512 байт (записываемый блок) и записать 4096 байт обратно. Аналогичная проблема проявляется и при отсутствии выравнивания, когда записываемый блок данных может быть достаточно большим и даже кратным 4096 байт, но при этом сдвинут относительно границ реальных секторов:
В современных условиях операции записи блоками меньше 4096 байт встречаются крайне редко, а вот проблема с выравниванием остаётся. Например, в старых Windows (до Windows Server 2008) при установке загрузочный раздел создаётся со смещением в 63 сектора. Так уж исторически сложилось с тех времён, когда BIOS использовал реальную геометрию диска вместо LBA. Разумеется, смещение в 63x512 не делится на 4096, что приводит к нарушению выравнивания для всех последующих разделов и снижению производительности. Впервые на данную проблему обратили внимание в связи с использованием RAID-контроллеров и необходимостью выравнивания разделов по границам страйпа и она была решена в Windows Vista/ Windows Server 2008 (и примерно в то же время — в других ОС) введением выравнивания по границам в 1024КиБ (1МиБ), т.е. первый раздел создается со смещением в 2048 512-байтных секторов.
Почему именно 1МиБ, если подойдёт меньшее смещение (главное — чтобы делилось на 4096 байт)? Просто потому, что нужен запас, ведь помимо физического диска в качестве блочного устройства могут выступать тома на RAID-контроллерах (с размером страйпа по умолчанию, например, у Adaptec в 256КиБ), SSD (с большим размером страниц) или образы дисков при использовании виртуализации, рекомендуемый размер NTFS-кластера для SQL или Exchange равен 64КиБ и т.д.
Проблема номер два — возможная потеря данных для сценариев с синхронной записью. Для ситуаций с записью блока меньше 4096 байт или невыравненного блока синхронной записи по факту не получится. Остаётся «научить» ОС не использовать при записи блоки меньше 4096 байт на диски 512E, но с этим есть определённые проблемы.
Microsoft
- Windows 8, 8.1
- Windows Server 2012, 2012 R2
- Windows 7 w/ MS KB 982018
- Windows 7 SP1
- Windows Server 2008 R2 w/ MS KB 982018
- Windows Server 2008 R2 SP1
- Windows Vista w/ MS KB 2553708
- Windows Server 2008 w/ MS KB 2553708
- Windows 8, 8.1
- Windows Server 2012, 2012 R2
Проверить выравнивание существующих разделов и задать смещение для новых разделов в Windows можно при помощи diskpart. Пример (раздел на диске 0 со смещением в 1024КиБ или 2048 512-байтных секторов):
Проверить проще всего через WMI (пример):
В колонке StartingOffset должно быть 1024КиБ для первого раздела, для остальных — должно делиться на 1024КиБ, это означает, что и на 4096 байт и все другие «хорошие числа» (размеры страйпов и NTFS-кластеров) всё будет делиться.
Напомню, что в современных Windows смещение в 1024КиБ и так используется по умолчанию, так что проверять/выставлять его вручную нужно лишь для ОС из «63-секторной» эпохи. При автоматическом создании GPT-разметки (через Disk Management) на 512N или 512E диске вы увидите смещение для первого раздела в 17КиБ. Это не повод для тревоги, так как это служебный раздел MSR. Первый стандартный раздел будет создан со смещением в 135266304 байт (129МиБ) — прекрасно делится на любое из наших «хороших чисел».
Linux
- RHEL 6.1
- SLES 11 SP2
- Ubuntu 13.10
- Ubuntu 12.04.4
- RHEL 6.1
- SLES 11 SP2
- Ubuntu 13.10
- Ubuntu 12.04.4
Посмотреть размеры физического и логического блоков можно в /sys/block/sdX/queue/physical_block_size и в /sys/block/sdX/queue/logical_block_size соответственно.
GNU Fdisk будет автоматически использовать смещение в 1МиБ при запуске с ключами -c и -u (отключить режим совместимости с DOS и использовать сектор в качестве единицы измерения). Обычный Fdisk не умеет работать с GPT, так что он бесполезен для дисков >2ТиБ, и нужно использовать Parted или GPT Fdisk. Последний по умолчанию использует для 512N/512E дисков нужное нам смещение в 2048 секторов:
Пример для GNU Parted (для 512N/512E дисков):
В LVM всё хорошо: смещение по умолчанию равно 1МиБ и размер PE (physical extent) кратен 1МиБ.
VMware
Статья в базе знаний VMware утверждает, что ни 512E, ни 4KN диски не поддерживаются. Поддержка дисков 4KN заявлена в vSphere 6.0.
С появлением VMFS-5 мы получили единый размер блока — 1МиБ и правильное 1МиБ-смещение для первого раздела. Раньше использовалось не всегда подходящее смещение в 64КиБ. Но всё это не отменяет заявления VMware о том, что 512E диски не поддерживаются. Видимо, это связано с тем, что формат VMDK хранит данные с гранулярностью 512 байт.
Прочие ОС
Mac OSX поддерживает Advanced Format начиная с Tiger. Остаются ещё FreeBSD и прочие *BSD, Oracle Solaris и множество других ОС, но детальное рассмотрение ситуации с Advanced Format дисками в них выходит за рамки данной статьи.
Сервисы Microsoft
Hyper-V
Несмотря на то, что диски 512E поддерживаются в Windows Server 2008 и 2008 R2 (см. в таблице требования по установленным KB), в Hyper-V появляется проблема: формат файлов виртуальных дисков VHD использует 512-байтные структуры для динамических («тонких») и дифференциальных VHD, что, естественно приводит к регулярным read-modify-write. Ситуация усугубляется тем, что для гостевой ОС виртуальный диск выглядит как имеющий физические сектора 512 байт. Используйте фиксированные VHD, но по-возможности не используйте диски 512E для размещения VHD-файлов.
В Windows Server 2012 появился формат VHDX, который не имеет вышеописанных проблем (его можно создать в любом виде — 512N/512E/4KN).
Exchange Server
- Все диски, используемые в группе обеспечения доступности (Database Availability Group, DAG) Exchange для хранения баз и логов, должны использовать одинаковый физический размер сектора.
- Диски 4KN не поддерживаются
- Диски 512E поддерживаются начиная с Exchange 2010 Service Pack 2
SQL Server
Ситуация та же, что и для Exchange Server — в отказоустойчивых конфигурациях для баз и логов на всех узлах должы использоваться диски с одинаковым физическим размером сектора.
При использовании Storage Spaces возникает интересная ситуация: презентуемый размер физического сектора оказывается равным 4КиБ вне зависимости от того, из каких дисков собран Storage Spaces (том Storage Spaces можно создать из разных дисков — 512N и 512E, смешивать с 4KN, естественно, нельзя, кроме случаев использования tiering'а с SSD). Формат VHDX (виртуальный диск) по умолчанию создаётся как 512E. В этом можно убедиться, запустив fsutil fsinfo ntfsinfo <имя диска>:
При использовании VHDX на томе Storage Spaces (или аппаратном RAID), состоящем из 4KN дисков, сам VHDX тоже желательно сделать 4KN:
Безопасно ли это для SQL и других приложений, использующих синхронную запись? Ответ — да, так как большая гранулярность хранения не нарушает целостности данных, на производительность это тоже не влияет, так как 4096 делится на 512.
Сервисы, использующие ESENT
Не совсем актуальная проблема в Windows Server 2008. Сервисы, использующие в работе Extensible Storage Engine API (AD, WINS, DHCP) могут упасть при изменении размера физического сектора (например, при миграции с 512N-диска на 512E). Подробное описание и хотфикс смотрите тут.
Прочее ПО
-
. поддерживает диски Advanced Format (512E и 4KN) начиная с версии 2012 revision 1798 Service Pack 2. Более ранние выпуски могут работать с дисками 512E, но Symantec утверждает, что подобное сочетание не поддерживается официально. не поддерживает диски 4KN.
Контроллеры
- Диски 4KN и 512N/512E смешивать в одном массиве нельзя.
- У контроллеров Adaptec и LSI метаданные размещаются в конце диска, пользовательское пространство доступно с LBA0. Это означает, что проблем с выравниванием для 512E дисков не будет.
- Массив из 4KN дисков так же будет иметь физический/логический размер сектора 4КиБ, т.е. для загрузки с них нужны GPT и UEFI.
- Не забывайте вместе с прошивкой обновлять утилиты управления и драйверы.
- Как будет презентоваться LUN, созданный на 512E дисках — 512N или 512E? Из того, что удалось проверить: контроллеры LSI 9260, Adaptec 6-й серии, СХД Infortrend ESDS сообщают 512N (логический/физический блоки 512 байт), т.е. проблема с синхронной записью остаётся. Обязательно используйте write-back кэш (естественно, с защитой) и UPS. Причём не исключено, что при смене прошивки СХД и контроллер могут внезапно повести себя «правильно», и LUN'ы превратятся в 512E со всеми вытекающими последствиями для совместимости.
Adaptec by PMC
- SAS HBA серий 5 и 6: поддерживают 512E, не поддерживают 4KN
- SAS HBA серий 6H и 7H: поддерживают 512E, 4KN — начиная с прошивки 10467.
- RAID контроллеры серий 7 и 8: поддерживают 512E, 4KN — начиная с прошивки 30862.
LSI/Avago
Это свойство как раз и отвечает за презентуемые хосту размеры блоков:
Default (0): при наличии в томе дисков 512E он презентуется как 512E. Если все диски — 512N, тогда том презентуется как 512N
Disabled (1): Том всегда презентуется как 512N несмотря на наличие дисков 512E
Forced (2): Том всегда презентуется как 512E даже при отсутствии дисков 512E
Emulation Type был портирован и на SAS2 контроллеры (LSI 2108/2208), но без значения Forced (2).
Программный RAID в чипсетах Intel (RST/RSTe)
4KN не поддерживается совсем, Intel RST на дисках 512E требует свежих драйверов.
Статья Диски GPT и MBR – разбор полётов
Таким образом, адрес конкретного сектора формируется из трёх составляющих – головка (выбирает диск), цилиндр на этом диске, и сектор на поверхности выбранного цилиндра. Рисунок ниже представляет трехмерный адрес CHS в визуальной форме:
Теперь проведём арифметические расчёты, чтобы определить макс.возможную ёмкоcть дисков с разметкой CHS. Для этого достаточно найти произведение всех значений BIOS и результат умножить на размер сектора. Для накопителей HDD, сектор в 512-байт является скорее правилом, чем исключением, хотя на твёрдотелых SSD он может достигать информационного веса в 4 Кб (его подогнали под размер виртуальной страницы ОЗУ). Но сейчас разговор об HDD, поэтому условимся считать сектор равным именно 512-байт. Тогда имеем..
цилиндров..(С): 14-бит = 16.383
головок. (H): 04-бит = 16
секторов. (S): 06-бит = 63
==========================================
16383*16*63 = 16.514.064 (всего секторов)
16514064*512 = 8.455.200.768 (всего байт)
Как видим, используя трёхмерную геометрию CHS, дисковый сервис биоса INT-13h способен оперировать накопителем с макс.размером
8 Gb. Ещё в эпоху неолита таких объёмов не хватало даже для домашнего пользования. Поэтому инженеры сняли ограничения CHS=16383/16/63 и добавили в биос расширенный сервис INT-13h, более известный как "Enhanced Disk Drive" , EDD. Если традиционный сервис адресовал секторы через регистры процессора CX и DX , то в расширенном ввели линейную адресацию LBA и т.н. "адресный пакет", который находится уже в памяти ОЗУ. Теперь регистры не ограничивают макс.номер сектора, и трюк позволил растянуть адресацию до LBA-64:
Хоть биос и поддерживал теперь 64-битный дисковый сервис, на практике использовался лишь LBA-32. В результате, ёмкость диска не превышала 4.294.967.295 всего секторов (32-бит) – при размере сектора 512-байт это получалось 2 тераБайт. На этот раз засаду устроила "таблица-разделов" накопителя, что в оригинале звучит как "MBR Partition Table" . Эта таблица описывает разделы уже самого жёсткого диска, и в ней под номер сектора LBA зарезервировано именно 32-бита.
Таким образом, инженерам пришлось положить на операционный стол и MBR, чтобы перекроить его под таблицу "GUID Partition Table" , в простонародье GPT. По сути требовал этого и сам прогресс, который решил "рубануть с плеча" и полностью искоренить устаревшую систему ввода-вывода BIOS, сделав бартер на более современный EFI. Рассмотрим бегло отличительные особенности этих таблиц, после чего завернём их в ассемблерный код.
2. Формат таблицы-разделов в секторе MBR
Термин MBR берёт своё начало от "Master Boot Record", что в дословно переводится как "Основная загрузочная запись". MBR занимает самый первый сектор с координатами: головка(0), цилиндр(0), сектор(1). Здесь нужно отметить, что в геометрии CHS отсчёт цилиндров и головок начинается с нуля, а секторов с единицы. Однако если мы имеем дело с выстроенными в ряд логическими блоками LBA, то нумеровать эти блоки (аля секторы) принято уже с нуля – такая вот муть..
Посмотрим на рисунок ниже, где представлена таблица-разделов отживающего свой век диска Seagate, объёмом 80 Gb. Здесь я открыл его в HEX-редакторе HxD как физический диск, и скопировал в новое окно только интересную на данный момент таблицу-разделов MBR. Как упоминалось выше, MBR – это равно один сектор, начиная с нуля и до адреса 0200h .
Первые 446-байт до смещения 01BEh отданы в распоряжение загрузчика ОС, а следующий за ним (выделенный) 64-байтный блок и есть таблица 4-х возможных разделов диска HDD. Правда я захватил в хвосте ещё и сигнатуру 55AAh по которой BIOS делает вывод, что сектор фактически является загрузочным. Каждый раздел Partition описывает своя 16-байтная запись (одна строка в нижнем окне), итого 16*4=64 байта. Ограниченный размер данной таблицы не позволяет создавать больше 4-х основных разделов, хотя раздел может быть и расширенным, тогда в нём присутствует своя таблица, ещё для 4-х его логических томов:
В окне "Partition Table" выше я собрал в блоки одноимённые поля всех четырёх разделов. Одна строка – это запись об одном разделе. Судя по этим данным, мой диск имеет всего 2-раздела, поскольку две последние строки забиты нулями. Коричневый первый байт со-значением 80h характеризует флаг загрузочного раздела – обычно это тот, с которого загружается Win. Два серых блока хранят адрес начала и конца раздела в формате CHS. Если там лежит значение FEFFFFh , значит поле не действительно и нужно использовать геометрию LBA.
Байт с типом раздела по смещению(4) информирует о том, основной это раздел, или расширенный. Для файловой системы NTFS сейчас встречаются только три типа: 07h = основной, 0Fh = расширенный раздел, а так-же идентификатор EEh = таблица разделов GPT (о ней ниже). Со списком остальных типов можно ознакомиться здесь .
Наибольший интерес в таблицах MBR представляют последние два 32-битных значения – это номер сектора LBA с которого начинается раздел (зелёный блок), и всего секторов LBA в разделе (красный блок). Тома и разделы не могут начинаться с середины дорожки диска, а только с нового цилиндра. Поэтому в зелёном блоке первого раздела мы видим значение 0000003Fh=63 . Если вспомнить, что в одной дорожке 63-сектора, то всё совпадает. Тогда выходит, что между MBR и началом первого раздела всегда имеются бесхозные 62-сектора (
32 Кб), которые мы можем подмять под себя.
Последний dword в красном блоке хранит общее число секторов в разделе: 02711637h = 40.965.687 . Теперь можно вычислить и его размер: 40965687*512=20Gb . Аналогично и для второго партишена: 06DF8F8Ah = 115.314.570 всего секторов, а размер: 115314570*512=59Gb .
Чтобы на программном уровне было проще обращаться к MBR, имеет смысл оформить этот сектор в структуру соответствующего вида. Вот что у меня из этого вышло:
Рассмотрев анатомические особенности таблицы-разделов MBR можно сделать вывод, что она действительно отжила свой век и ей давно уже пора на покой. Во-первых, чтобы при малейшем чихе не потерять навсегда терабайты своих данных, обязательно нужно иметь резервную копию этой таблицы, с её контрольной суммой. Ведь превратить в труху диски MBR проще-простого – достаточно элементарно сбросить "Boot-Flag", сменить тип по-смещению(4) на какой-нибудь от фонаря, или поменять местами два последних поля LBA. Всё.. сушим вёсла.. После этих действий, система в лучшем случае откажется грузиться, а в худшем – вообще не распознает дисковые тома, что приведёт к полной потере информации. Все эти просчёты были учтены в более современной таблице-разделов GPT – разберём её на атомы..
3. Формат таблицы-разделов GPT
GPT это "GUID Partition Table" . Права на неё принадлежат Intel, коллектив которой разработал её в 90-х прошлого столетия. Однако распространение таблица получила только с приходом интерфейса EFI "Extensible Firmware Interface" в конце 2000-х. По задумке инженеров, весь хлам из MBR планировалось выкинуть за борт, однако пережившие себя древние устройства не разделяли такую позицию, и грязно высказываясь разработчикам пришлось тащить за собой воз обратной совместимости.
В результате, в секторе(0) GPT по прежнему лежит MBR, только теперь он ущербный без загрузчика (первые 440-байт, забиты нулями), а осталась лишь описывающая всего один раздел запись. Причём последний дворд в ней под кличкой "всего LBA" выставлен на максимум FFFFFFFFh (нет места на диске), а флаг с типом раздела по смещению(4) имеет значение EEh . Это сделано для того, чтобы не знакомый с GPT софт времён динозавров, не повредил случайно таблицу GUID.
Здесь видно, что первые 33-сектора заняты служебкой, а непосредственно под данные выделяются секторы начиная с LBA(34). Точная ксерокопия основной таблицы притаилась в хвосте и ждёт своего часа. При каждом включении машины, код системного EFI пересчитывает контрольную сумму GPT, которая хранится по смещению(10h) в её заголовке. При несовпадении CRC, основной заголовок вместе со-всеми записями восстанавливается из резервной копии, на автомате корректируя таким образом служебную инфу.
Согласно документации, вне зависимости от реального числа разделов 128 или всего пару-штук, они начинаются исключительно с сектора LBA(34). Однако на моём буке, первый раздел сдвинут ещё дальше и занимает позицию LBA(2048), хотя в заголовке указано правильно 22h=34 . Видимо в доках имелось в виду минимальный сектор(34), а дальше по настроению. Так-что их высказывания можно классифицировать по разному, а лучше не доверяя проверять всё на практике.
3.1. Заголовок таблицы "GPT -Header "
Программно распознать диск с разметкой GPT можно по сигнатуре "EFI PART" в начале сектора LBA(1), или-же по идентификатору типа-раздела EEh в секторе LBA(0) таблицы MBR. Ниже приводится описание полей данного заголовка, всего 1 сектор = 512-байт:
Обратите внимание, что в заголовке имеются две контрольные суммы CRC32.
Первая по смещению(10h) – сумма исключительно самого заголовка, а вторая с офсетом(58h) – всех имеющихся записей "Partition Entry". Так разрабы закрыли GPT аж на два амбарных замка, а специальная процедура дотошного EFI постоянно их проверяет. В случае малейшего несоответствия, на территории сразу включается ревун и данные тут-же восстанавливаются из резервной копии. Достопочтенный BIOS со-своим MBR о таких мелочах мог только мечтать. Остальные поля заголовка пояснений вроде не требуют.
3.2. Записи о разделах "Partition Entry "
В заключении рассмотрим формат паспорта каждого из разделов. Как упоминалось выше, таблица GPT поддерживает макс.128 разделов, и в 33-х секторах для каждого из них зарезервировано место под описатель. Лично мне не встречались диски с таким кол-вом томов, но как говорят: "лучше еврей без бороды, чем борода без еврея" – пусть лежат на чёрный день, авось когда-нибудь понадобятся.
Обратите внимание на 64-битную маску атрибутов по смещению(30h). Большая часть битов в ней отправлена в резерв, а список активных представлен ниже. Если в двух словах, то у обычных разделов маска имеет значение нуль, т.е. все биты сброшены. А если какой-то из них взведён (как-правило нулевой или под номером 63), то он означает следующее:
В записях разделов огромную роль играет GUID – "Globally Unique Identifier" , или глобально-уникальный идентификатор. В каждой записи по два таких GUID'a (см.предыдущий скрин с форматом). Первый – системный и определяет тип данного раздела, по аналогии с байтом "типа" по смещению(4) в таблице MBR. Второй GUID – это просто рандомный номер раздела, по которому виндовый диспетчер-дисков монтирует том в систему. Кстати если в ком.строке запросить утилиту mountvol.exe без параметров, то она сбросит на консоль список именно этих идентификаторов, с назначенными им буквами разделов.
Ниже перечислены некоторые GUID, предопределяющие тип раздела в операционной системе Win. Например разделы с пользовательскими данными будут иметь тип "Basic Data Partition" , а раздел типа "EFI System Partition" зарезервирован для кода загрузчика EFI. В таблице GPT любого накопителя их GUID'ы будут одинаковыми, поскольку они являются глобальными внутри системы:
4. Практика – сбор и вывод информации о разделах
В практической части напишем небольшую утилиту, которая позволит динамически определить способ разметки диска MBR или GPT. Дальше, код в цикле обойдёт все записи в "Partition Table" и отрапортует о собранной информации на консоль. Это будет просто демонстрацией того, как можно подобраться на программном уровне к данным таблицы-разделов. А что дальше делать с этими данными – это уже вопрос к нашей совести. Поскольку в атрибутах разделов GPT имеется бит(60), то можно взвести его в записи любого раздела, в результате чего раздел станет доступным только для чтения, без возможности записи на него. Или-же скрыть его к чертям, установив в единицу бит(62).
Небольшую проблему может создать вывод значений GUID на экран в приглядном виде типа: . Для этого воспользуемся функцией из библиотеки ole32.dll StringFromGUID2() . Всё-что ей нужно, это указатель на GUID для преобразования, и указатель на приёмный буфер для результирующей строки. Если на выходе получим нуль, значит приёмный буф слишком мал и в аргумент "cchMax" вернётся требуемая длинна. Вот её прототип:
Эта функция сбрасывает в буфер GUID в виде Unicode-строки, значит для вывода на консоль её нужно будет преобразовать в ASCII, просто читая по 2-байта, и сохраняя в тот-же буфер по одному (т.е. отсекать парные нули). Весь алгоритм программы можно представить так:
1. Запросить номер диска на случай, если их несколько в системе.
2. Открыть указанный диск при помощи CreateFile() обязательно с шарой Write , чтобы диск был доступен остальным для записи.
3. Функцией VirtualAlloc() выделить память под 10-секторов диска (в идеале под 33-сектора, но хватит и 10-ти).
4. Через ReadFile() считать секторы из диска в память (чтение разрешено всем, а запись только админу).
5. Проверкой байта "тип-раздела" в MBR, распознать способ разметки GPT или MBR (байт должен иметь значение EEh).
6. В зависимости от результата, спроецировать соответствующую структуру на считанные сектора, и пропарсить их.
Мы не можем заранее знать, на машину какой разрядности попадёт наш код, 32 или 64-бит. Поэтому в таких случаях лучше писать 32-битное приложение. Если оно попадёт на х64, то отработает через её WOW64 (Windows-on-Windows). Зато 64-битное приложение вообще не запуститься на х32, и мы обломаемся по полной. Так-как большинство полей в GPT 64-битные, то придётся оперировать ими через сопр FPU. Исходник этой задумки на лексиконе ассемблера FASM представлен ниже. Инклуд с описанием структур MBR/GPT я спрятал в скрепку:
Посмотрим, что в итоге получили..
Значит перед нами таблица GPT, в которой сначала идёт заголовок с информацией о самом диске, а дальше логи из записей "Partition Entry". В заголовке видно, что резервная копия заголовка лежит в конце пространства, в секторе(976773167). Сама таблица лежит в секторе(2) – это текущий сектор, ..а разделы с данными (как и утверждал производитель) начинаются с сектора(34). Чтобы вычислить ёмкость раздела в секторах, нужно от Last отнять First-LBA .
Однако в моём случае, внутри записи первого раздела видим начальный сектор(2048), а не 34. Раздел размером 500 Мб и в его атрибутах взведены биты 0 и 63, что означает "Защищённый ОЕМ-раздел, без буквы" , т.е. не отображается в проводнике Win. Это бокс для различных драйверов и прочей системной утвари, которую любезно сбросил туда производитель моего бука. Нужно сказать, что и последующие два раздела тоже из этой-же кухни с установленным битом(63), только они не принадлежат вендору ОЕМ (разработчику). В разделе EFI лежит загрузчик ОС размером 100 Мб (старушка MBR его таскала с собой), а в третьем разделе – барахло мелкомягких.
Доступ к стартовым секторам диска с правами на запись открывает большие возможности. В своё время это было излюбленное место червей и всякой нечисти, поэтому начиная с Висты, MS отобрала у нас эти права (привет Жанне Рутковской, с её "голубой пилюлей"). Читать – пожалуйста, а вот записывать в начало диска (до файловой системы), юзеру нельзя. Чтобы сидя на нарах не ждать с воли сухарей, мы всегда должны помнить об уголовной ответственности за порчу чужой информации. Поэтому всё сказанное здесь носит чисто оборонительный характер, чтобы мы были осведомлены, как при программных сбоях можно восстановить работоспособность своего накопителя. Особенно актуально это для размеченных в формате MBR дисков, где самостоятельная правка пару байт может сэкономить Вам честно заработанные шекели.
В скрепке лежит готовый исполняемый файл для тестов, исходник загрузчика из MBR, а так-же инклуд с описанием структур "Partition Table". Всем удачи, пока!
Advanced Format в дисках корпоративного класса. Что нас ждёт?
Речь пойдёт о дисках корпоративного класса последний серий. Десктопные HDD и позиционируемые для NAS или видеонаблюдения сюда не попали.
| Вендор | Серия | Форм-фактор | Интерфейсы | Скорость вращения шпинделя, об/мин | Дополнительно | |||
| Seagate | Enterprise Performance 10K HDD (10k.8) | 2.5" | SAS | 10000 | Y | Y | Y | для 512N ёмкость ограничена: 600/1200ГБ |
| Seagate | Enterprise Performance 15K HDD (15k.5) | 2.5" | SAS | 15000 | Y | Y | Y | 32ГБ встроенного SSD-кэша |
| Seagate | Enterprise Capacity 2.5 HDD (V.3) | 2.5" | SAS, SATA | 7200 | Y | Y | ||
| Seagate | Enterprise Capacity 3.5 HDD (V.4) | 3.5" | SAS, SATA | 7200 | Y | Y | ||
| Seagate | Archive HDD | 3.5" | SATA | 7200 | Y | Позиционируются для архивного применения, меньше MTBF и хуже BER | ||
| Seagate | Terascale HDD | 3.5" | SATA | 5900/7200 | Y | Позиционируются для облачного применения, меньше MTBF и хуже BER | ||
| HGST | Ultrastar C10K1800 | 2.5" | SAS | 10000 | Y | Y | Y | для 512N ёмкость ограничена: 300/600/900/1200ГБ |
| HGST | Ultrastar C15K600 | 2.5" | SAS | 15000 | Y | Y | Y | |
| HGST | Ultrastar C7K1000 | 2.5" | SAS | 7200 | Y | |||
| HGST | Ultrastar He 8 | 3.5" | SAS, SATA | 7200 | Y | Y | ||
| HGST | Ultrastar He 6 | 3.5" | SAS, SATA | 7200 | Y | |||
| HGST | Ultrastar 7K6000 | 3.5" | SAS, SATA | 7200 | Y | Y | ||
| HGST | MegaScale DC 4000.B | 3.5" | SATA | 5400 | Y | Позиционируются для облачного применения, меньше MTBF и хуже BER | ||
| WD | Xe | 2.5"/3.5" | SAS | 10000 | Y | |||
| WD | Re | 3.5" | SATA | 7200 | Y | |||
| WD | Se | 3.5" | SATA | 7200 | Y | Позиционируются для облачного применения, меньше MTBF и хуже BER | ||
| WD | Ae | 3.5" | SATA | 5760 | Y | ? | Позиционируются для архивного применения, меньше MTBF и хуже BER | |
| Toshiba | AL13SE | 2.5" | SAS | 10000 | Y | |||
| Toshiba | AL13SX | 2.5" | SAS | 15000 | Y | |||
| Toshiba | AL13SEL | 3.5" | SAS | 10000 | Y | |||
| Toshiba | MG03ACA/MG03SCA | 3.5" | SAS, SATA | 7200 | Y | |||
| Toshiba | MG04ACA | 3.5" | SATA | 7200 | Y | Y | ||
| Toshiba | MG04SCA | 3.5" | SAS | 7200 | Y | Y | ||
| Toshiba | MC04ACA | 3.5" | SATA | 7200 | Y | Позиционируются для облачного применения, меньше MTBF и хуже BER |
SSD имеют свои особенности. Читать и записывать данные можно страницами, размер которых составляет 2–4–8–16КиБ в зависимости от архитектуры SSD. При этом для записи нужно обеспечить предварительное стирание ячеек, которое осуществляется не постранично, а блоками по несколько сотен страниц. Например, Samsung 840 EVO имеет блоки по 2МиБ, каждый из которых состоит из 256-ти страниц по 8КиБ. При этом, естественно, любой презентуемый хосту размер блока — 512 или 4096 байт — будет абстракцией.
Некоторые из современных SAS/SATA SSD эмулируют 512E-диск, но большая часть из соображений совместимости — 512N. Каких-либо особых мер в связи с этим предпринимать не требуется, так как в SSD корпоративного класса содержимое кэша обязательно защищается от потери питания. Достаточно обеспечить выравнивание по размеру страницы.
Некоторые PCI-E SSD, например, производства Fusion IO дают возможность при помощи фирменных утилит изменить при форматировании размер логического сектора, т.е. переключаться между 512E и 4KN режимами. Для некоторых SSD с интерфейсом SAS это тоже возможно, например, Seagate 1200 поддерживает изменение размера сектора обычным sg_format. Переход на 4КиБ сектор в некоторых сценариях может существенно поднять производительность.
Читайте также: