Казалось бы, что про диски Advanced Format за последние 4 года успели узнать все. Публикаций действительно много, но настало время рассмотреть все технические подробности и подводные камни в одной большой статье. Речь пойдёт об использовании AF-дисков в серверах, и я заметил, что для большинства администраторов даже в крупных компаниях знание предмета в большинстве случаев сводится к «это как-то связано с современными дисками, но у меня всё работает».

Что такое Advanced Format

Advanced Format — новый формат разметки секторов, используемый в некоторых жёстких дисках. Вместо традиционного сектора размером 512 байт используется 4096 байт. Некоторые диски SCSI/SAS/FC могут использовать 520- и 528-байтные «толстые» сектора для дополнительного контроля целостности данных ^[1], но это не относится к теме данной статьи.

Увеличение размера сектора в 8 раз связано с необходимостью повышения эффективности размещения данных на современных дисках. Накладные расходы, связанные с 512-байтной разметкой, начинают мешать дальнейшему увеличению ёмкости HDD. Помимо служебных полей в каждом 512-байтном секторе присутствует поле с кодом коррекции ошибок (ECC) длиной в 50 байт. В 4096-байтном секторе длина ECC-поля составляет 100 байт. Общее эффективность хранения данных удалось улучшить примерно на 10%.

Естественно, поддержка нестандартных секторов требуется со стороны дисковых контроллеров и операционных систем. Для решения проблем с совместимостью был ввёден дополнительный стандарт 512E, который обозначает диски с физическим размером сектора 4096 байт, но при этом эмулирующие обычный размер сектора в 512 байт. Advanced Format диски без эмуляции обозначаются 4KN. Таким образом, сейчас существует три варианта разметки:

Формат	Логический размер сектора	Физический размер сектора
512N	512 байт	512 байт
512E	512 байт	4096 байт (4КиБ)
4KN	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

Для ОС Microsoft есть следующие официальные (первоисточник ^[2]) данные:

Формат	Логический размер сектора	Физический размер сектора	Совместимые ОС
512E	512 байт	4096 байт (4КиБ)	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
4KN	4096 байт (4КиБ)	4096 байт (4КиБ)	Windows 8, 8.1 Windows Server 2012, 2012 R2

Обратите внимание на дополнительное напоминание о том, что Windows Server 2003 R2, Windows XP и другие ОС, основанные на кодовой базе XP (например, Windows Home Server 1.0, Windows Small Business Server 2003, 2003 R2), хоть и могут функционировать в связке с 512E дисками, но Microsoft предостерегает от использования таких дисков: если проблему с выравниванием ещё можно решить, то проблемы с производительностью или с потенциальной потерей данных ^[3] при потере питания во время read-modify-write никак не обойти.

Проверить выравнивание существующих разделов и задать смещение для новых разделов в Windows можно при помощи diskpart. Пример (раздел на диске 0 со смещением в 1024КиБ или 2048 512-байтных секторов):

	select disk 0
	create partition primary align=1024
	

Проверить проще всего через WMI (пример):

	wmic partition get Blocksize,StartingOffset, Name
	BlockSize  Name                          StartingOffset
	512        Диск #0, раздел #0  1048576
	512        Диск #0, раздел #1  368050176
	512        Диск #2, раздел #0  135266304
	512        Диск #1, раздел #0  1048576

В колонке StartingOffset должно быть 1024КиБ для первого раздела, для остальных — должно делиться на 1024КиБ, это означает, что и на 4096 байт и все другие «хорошие числа» (размеры страйпов и NTFS-кластеров) всё будет делиться.

Напомню, что в современных Windows смещение в 1024КиБ и так используется по умолчанию, так что проверять/выставлять его вручную нужно лишь для ОС из «63-секторной» эпохи. При автоматическом создании GPT-разметки (через Disk Management) на 512N или 512E диске вы увидите смещение для первого раздела в 17КиБ. Это не повод для тревоги, так как это служебный раздел MSR. Первый стандартный раздел будет создан со смещением в 135266304 байт (129МиБ) — прекрасно делится на любое из наших «хороших чисел».

Linux

Таблица совместимости для Linux (приведены только распространённые серверные дистрибутивы):

Формат	Логический размер сектора	Физический размер сектора	Совместимые ОС
512E	512 байт	4096 байт (4КиБ)	RHEL 6.1 SLES 11 SP2 Ubuntu 13.10 Ubuntu 12.04.4
4KN	4096 байт (4КиБ)	4096 байт (4КиБ)	RHEL 6.1 SLES 11 SP2 Ubuntu 13.10 Ubuntu 12.04.4

Для других дистрибутивов можно ориентироваться на версию ядра (>2.6.31) и версии утилит для разбивки диска: GNU Fdisk >1.2.3 или GNU Parted >2.1

Посмотреть размеры физического и логического блоков можно в /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 ^[4]. Последний по умолчанию использует для 512N/512E дисков нужное нам смещение в 2048 секторов:

	Disk /dev/sde: 7814037168 sectors, 3.6 TiB
	Logical sector size: 512 bytes
	Disk identifier (GUID): BE7D7D71-F6ED-4371-ACFE-B04819A4DDC2
	Partition table holds up to 128 entries
	First usable sector is 34, last usable sector is 7814037134
	Partitions will be aligned on 2048-sector boundaries
	Total free space is 7814037101 sectors (3.6 TiB)

Пример для GNU Parted (для 512N/512E дисков):

	# создаём новую GPT разметку
	mklabel gpt
	# создаём раздел на всё свободное пространство со смещением в 2048 секторов
	(parted) mkpart part1 2048s 100%
	(parted) print
	Model: ATA WDC WD40EFRX-68W (scsi)
	Disk /dev/sde: 7814037168s
	Sector size (logical/physical): 512B/4096B
	Partition Table: gpt

	Number  Start  End          Size         File system  Name   Flags
	1      2048s  7814035455s  7814033408s               part1

В LVM всё хорошо: смещение по умолчанию равно 1МиБ и размер PE (physical extent) кратен 1МиБ.

	# проверяем смещение
	#pvs /dev/sde -o+pe_start
	PV         VG     Fmt  Attr PSize PFree 1st PE
	/dev/sde   VolRed lvm2 a--  3.64t 3.64t   1.00m

	# проверяем размер PE
	#pvdisplay /dev/sde
	--- Physical volume ---
	PV Name               /dev/sde
	VG Name               VolRed
	PV Size               3.64 TiB / not usable 3.84 MiB
	Allocatable           yes
	PE Size               4.00 MiB
	Total PE              953861
	Free PE               953861
	Allocated PE          0
	PV UUID               9AfJr9-OOtC-PB34-dUnq-kCDK-L1fN-aTAxus

VMware

Статья в базе знаний VMware ^[5] утверждает, что ни 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, который не имеет вышеописанных проблем.

Exchange Server

Есть особенности, связанные с репликацией в DAG:

• Все диски, используемые в группе обеспечения доступности (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, естественно, нельзя). Формат VHDX (виртуальный диск) всегда выглядит как 512E. В этом можно убедиться, запустив fsutil fsinfo ntfsinfo <имя диска>:

	Bytes Per Sector  :               512
	Bytes Per Physical Sector :       4096

Безопасно ли это для SQL ^[6] и других приложений, использующих синхронную запись? Ответ — да, так как большая гранулярность хранения не нарушает целостности данных, на производительность это тоже не влияет, так как 4096 делится на 512.

Сервисы, использующие ESENT

Не совсем актуальная проблема в Windows Server 2008. Сервисы, использующие в работе Extensible Storage Engine API (AD, WINS, DHCP) могут упасть при изменении размера физического сектора (например, при миграции с 512N-диска на 512E). Подробное описание и хотфикс смотрите тут ^[7].

Прочее ПО

Очевидно, что софт, предназначенный для управления разделами (клонирования, перемещения, изменения размеров) и для автоматизации резервного копирования должен учитывать особенности работы с дисками Advanced Format. Вот как обстоят дела:

• Продукты Acronis ^[8].
• Symantec Backup Exec ^[9] поддерживает диски Advanced Format (512E и 4KN) начиная с версии 2012 revision 1798 Service Pack 2. Более ранние выпуски могут работать с дисками 512E, но Symantec утверждает, что подобное сочетание не поддерживается официально.
• Symantec Norton Ghost ^[10] не поддерживает диски 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.

Списки совместимости для контроллеров Adaptec ^[11].

LSI/Avago

Контроллеры на базе чипов LSI используют Dell, IBM, Lenovo, Fujitsu, Intel и Supermicro. Соответствие между моделями от LSI и OEM-вариантами можно установить по чипу.

• Старые контроллеры на базе LSI1078: не поддерживают диски Advanced Format совсем
• LSI 3ware серии 9750 на базе LSI2108 и более ранние 3ware: не поддерживают диски Advanced Format совсем.
• LSISAS2108 (LSI 9260/61/80): поддерживают 512E начиная с прошивки MR4.8, 4KN не поддерживают. Список совместимости ^[12] (4KN диски присутствуют, но, видимо, относятся к LSI 2208, см. ниже).
• LSISAS2208 (LSI 9265/66/71/85/86): поддерживают 512E начиная с прошивки MR5.5, поддерживают 4KN начиная с прошивки MR5.8. Список совместимости ^[12].
• LSISAS3108 (LSI 9361/80): поддерживают 512E и 4KN. Список совместимости ^[13].
• SAS HBA на базе LSISAS2008 и LSISAS2308 (LSI 9211/9200/9207): поддерживают 512E и 4KN. Список совместимости ^[14].
• SAS HBA на базе LSISAS3008 (LSI 9311/9300): поддерживают 512E и 4KN. Список совместимости ^[15].
• RAID на базе LSISAS2008 (LSI 9240, прошивка iMR): поддерживают 512E, 4KN не поддерживают. Список совместимости ^[16].
• RAID на базе LSISAS3008 (LSI 9340, прошивка iMR): поддерживают 512E, 4KN не поддерживают. Список совместимости ^[17].

Программный RAID в чипсетах Intel (RST/RSTe)

4KN не поддерживается совсем, Intel RST на дисках 512E требует свежих драйверов ^[18].

Advanced Format в дисках корпоративного класса. Что нас ждёт?

Речь пойдёт о дисках корпоративного класса последний серий. Десктопные HDD и позиционируемые для NAS или видеонаблюдения сюда не попали.

Вендор	Серия	Форм-фактор	Интерфейсы	Скорость вращения шпинделя, об/мин	512N	512E	512KN	Дополнительно
Seagate	Enterprise Performance 10K HDD (10k.8) [19]	2.5"	SAS	10000	Y	Y	Y	для 512N ёмкость ограничена: 600/1200ГБ
Seagate	Enterprise Performance 15K HDD (15k.5) [20]	2.5"	SAS	15000	Y	Y	Y	32ГБ встроенного SSD-кэша
Seagate	Enterprise Capacity 2.5 HDD (V.3) [21]	2.5"	SAS, SATA	7200		Y	Y
Seagate	Enterprise Capacity 3.5 HDD (V.4) [22]	3.5"	SAS, SATA	7200		Y
Seagate	Archive HDD [23]	3.5"	SATA	7200			Y	Позиционируются для архивного применения, меньше MTBF и хуже BER
Seagate	Terascale HDD [24]	3.5"	SATA	5900/7200		Y		Позиционируются для облачного применения, меньше MTBF и хуже BER
HGST	Ultrastar C10K1800 [25]	2.5"	SAS	10000	Y	Y	Y	для 512N ёмкость ограничена: 300/600/900/1200ГБ
HGST	Ultrastar C15K600 [26]	2.5"	SAS	15000	Y	Y	Y
HGST	Ultrastar C7K1000 [27]	2.5"	SAS	7200	Y
HGST	Ultrastar He8 [28]	3.5"	SAS, SATA	7200		Y	Y
HGST	Ultrastar He6 [29]	3.5"	SAS, SATA	7200	Y
HGST	Ultrastar 7K6000 [30]	3.5"	SAS, SATA	7200		Y	Y
HGST	MegaScale DC 4000.B [31]	3.5"	SATA	5400		Y		Позиционируются для облачного применения, меньше MTBF и хуже BER
WD	Xe [32]	2.5"/3.5"	SAS	10000	Y
WD	Re [33]	3.5"	SATA	7200	Y
WD	Se [34]	3.5"	SATA	7200		Y		Позиционируются для облачного применения, меньше MTBF и хуже BER
WD	Ae [35]	3.5"	SATA	5760		Y	?	Позиционируются для архивного применения, меньше MTBF и хуже BER
Toshiba	AL13SE [36]	2.5"	SAS	10000	Y
Toshiba	AL13SX [37]	2.5"	SAS	15000	Y
Toshiba	AL13SEL [38]	3.5"	SAS	10000	Y
Toshiba	MG03ACA/MG03SCA [39]	3.5"	SAS, SATA	7200	Y
Toshiba	MG04ACA [40]	3.5"	SATA	7200		Y	Y
Toshiba	MG04SCA [41]	3.5"	SAS	7200		Y	Y
Toshiba	MC04ACA [42]	3.5"	SATA	7200		Y		Позиционируются для облачного применения, меньше MTBF и хуже BER

Тенденцию вы видите сами — Advanced Format окончательно проник из десктопного сегмента в корпоративный. Быстрые SAS диски 10/15 тыс. об/мин ещё выпускаются в варианте 512N, но наращивание плотности заставляет производителей использовать 4КиБ-сектора: Seagate 10k.8 и HGST Ultrastar C10K1800 ёмкостью 1800ГБ доступны только в вариантах 512E и 4KN. Все диски объёмом больше 5ТБ за исключением HGST Ultrastar He⁶ — только Advanced Format.

SSD

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КиБ сектор в некоторых сценариях ^[43] может существенно поднять производительность.

Выводы

1. Диски 512E не подходят для использования в серверах с устаревшими ОС, которые игнорируют размер физического сектора. В десктопных применениях это не имеет большого значения, так никто синхронную запись как правило не использует.
2. Внимательно изучите свою инфраструктуру: ОС, используемые сервисы, контроллеры, СХД, режимы кэширования на контроллерах и СХД. При наличии потенциальных проблем с производительностью и/или целостностью данных примите необходимые меры.
3. Проблемы с устаревшими ОС можно обойти при помощи виртуализации, но по-прежнему нужно обращать внимание на выравнивание разделов.

Ссылки

• IBM DeveloperWorks: Linux on 4 KB sector disks: Practical advice ^[44]
• Документация RHEL6: IO limits и IO hints в Linux ^[45]
• Выравнивание в fdisk, LVM и MD ^[46]
• Поддержка дисков с большим размером сектора в Hyper-V ^[47]
• Группы обеспечения доступности Exchange Server 2010 и размер сектора ^[48]
• Использование Hyper-V на дисках с большим размером сектора в Windows Server 2008 и 2008 R2 ^[49]
• SQL Server и новые диски с размером сектора 4K ^[50]
• Ошибка «Windows Setup could not configure Windows on this computer’s hardware» при установке Windows 7 или Windows Server 2008 R2 ^[51]
• Проблемы в приложениях, использующих Extensible Storage Engine API (ESENT), при изменении размера физического сектора ^[51]
• Understanding 4KB Sector Support for Oracle Files ^[52]
• Effect from innodb log block size 4096 bytes ^[43]

Автор: quartz64

Источник ^[53]