T10 DIF/DIX: защита данных от тихой порчи

Одна из самых неприятных категорий отказов в хранилищах — тихая порча данных (SDC, silent data corruption). Она случается редко, но когда случается, обнаруживается обычно слишком поздно: данные уже записаны, реплицированы, подхвачены бэкапом и начинают всплывать лишь при чтении, спустя месяцы. Именно для этой проблемы комитет T10 стандартизировал механизм дополнительной защиты блоков — DIF/DIX, или «Data Integrity Field» и «Data Integrity Extensions».

Эта статья — второе погружение в «Скрытые глубины SCSI», где мы разберём, как устроена защита данных на уровне блоков, почему обычных CRC диска недостаточно и что именно контролирует операционная система, HDD/SSD и HBA, когда речь заходит о T10 DIF/DIX.

Зачем нужен DIF/DIX: откуда берётся тихая порча

Даже в системах с ECC-памятью, RAID и проверками файловой системы остаётся участок пути, где данные могут повредиться:

• при передаче по шине между CPU, контроллером и устройством;
  
• при DMA-перемещениях;
  
• при работе внутри HBA (особенно со старыми прошивками);
  
• при передаче через расширители SAS;
  
• при работе контроллера SSD над NAND-страницами и FTL.

Обычный 512-байтовый или 4K блок не содержит дополнительной информации, позволяющей хосту или диску понять: «это действительно тот блок, который мы хотели прочитать/записать?»

Задача DIF/DIX — вставить в цепочку защиты ещё один уровень контроля, который работает не только на самом диске, но и между всеми участниками I/O-траектории.

Что такое T10 DIF

T10 DIF (Data Integrity Field) — это расширение SCSI, позволяющее хранить дополнительные 8 байт метаданных для каждого логического блока. Эти 8 байт называются Protection Information (PI) и состоят из:

1. Guard (2 байта)
   CRC-16, покрывающий весь блок данных. Это основная защита от битовых ошибок.
   
2. Application Tag (2 байта)
   Опциональное поле, используемое хостом или файловой системой для собственных проверок.
3. Reference Tag (4 байта)
   Как правило — номер LBA блока. Позволяет диску убедиться, что блок не перепутали местами.

Если диск или контроллер обнаруживает несоответствие любого из этих полей, он возвращает ошибку чтения/записи.

Три режима защиты: Type 0, Type 1, Type 2, Type 3

Стандарт T10 определяет несколько форматов Protection Information в зависимости от требований к проверке:

Type 0 — отсутствие DIF
Стандартные блоки без Protection Information. Обычные SATA/SAS диски, consumer NVMe SSD, legacy массивы.

Type 1 — полная защита с привязкой к LBA

• Reference Tag = LBA (младшие 32 бита)
• Guard Tag (CRC-16) проверяется всегда
• Application Tag опционален (0xFFFF = игнорировать)
• Reference Tag автоматически инкрементируется для каждого 512B сектора

Проверки при I/O:

• Guard Tag: соответствие CRC данных
• Reference Tag: Expected LBA == Actual Reference Tag
• Application Tag: если задан хостом

Защищает от: битовых ошибок, misdirected writes, stale data

Применение: Enterprise SAS/SATA HDD, NVMe с PI, большинство современных систем

Type 2 — Reference Tag задаётся хостом

• Reference Tag != LBA, задаётся произвольно хостом
• При последовательных операциях инкрементируется
• Позволяет группировать связанные блоки одним идентификатором

Пример использования:

Работа со снепшотом:

- Original LBA 1000-1999 с Reference Tag 0x0000-0x03E7
- Clone на LBA 5000-5999 с тем же Reference Tag 0x0000-0x03E7
→ Диск видит целостность группы независимо от физического LBA

Применение: Специализированные массивы с thin provisioning, снэпшоты

Type 3 — только Guard Tag

• Reference Tag не проверяется (игнорируется или = 0xFFFFFFFF)
• Guard Tag (CRC-16) работает
• Application Tag работает

Зачем нужен:

• Диски > 16TB с 4K секторами (LBA > 2^32, 32 бита недостаточно)
• Copy/snapshot операции где LBA переназначаются
• Системы с динамическим маппингом LBA (thin provisioning)
• Случаи где защита от битовых ошибок важна, но tracking LBA не критичен

Применение: Крупные массивы, системы с агрессивной дедупликацией

Где хранятся эти 8 байт?

Protection Information хранится как расширение физического сектора, не входящее в пользовательскую ёмкость диска.

Format 0 (Type 0) — без PI:

512B или 4096B блоки
Хост видит: 512B/4K 

Format 1 (Type 1/2/3) — PI только на диске:

Хост отправляет: 512B data
Диск хранит: 520B (512B data + 8B PI)
Хост видит: 512B блоки
PI генерируется/проверяется диском или HBA

(аналогично 4096 / 4160 байт на блок)

Format 2 (Type 1/2/3) — PI end-to-end:

Хост отправляет: 520B (512B data + 8B PI)
Диск хранит: 520B
Хост видит: 520B блоки

(аналогично 4096 / 4160 байт на блок)

Что такое DIX (Data Integrity Extensions)

DIF в типичной реализации защищает путь от HBA до диска, но не защищает путь от приложения до HBA.

DIX это набор механизмов, которые позволяют “поднять” защиту до уровня приложения.

В системах, где настроен DIX, защитную информацию (PI) генерирует либо приложение, либо файловая система. Это повышает сохранность данных, делая ее сквозной от приложения до диска, однако реализация весьма непростая, поэтому на практике используется редко, как правило на уровне продвинутых СХД. 

Почему DIX не популярен?

Несмотря на теоретические преимущества, software DIX редко используется:

1. Сложность: требует изменений в файловой системе, ядре, драйверах HBA
2. Дополнительная нагрузка: Процессор тратит циклы на генерацию CRC вместо HBA
3. Совместимость: не все приложения работают с 520B блоками
4. Оптимизации FS: многие оптимизации (page coalescing) ломаются с PI

Результат: большинство систем используют HBA-generated PI (DIF без DIX), что даёт 80% защиты при 20% сложности.

Аппаратная поддержка: кто умеет DIF/DIX

В клиентском железе поддержку DIF/DIX найти сложно. Встречается в основном в enterprise-классе:

• SAS-HDD (Seagate Exos, Toshiba MG, WD Ultrastar)
  
• SAS-SSD (Micron, Intel/Solidigm, Samsung)
  
• HBA LSI/Broadcom 93xx/94xx/95xx/96xx
  

SATA почти никогда не поддерживает DIF/DIX, хотя SATA AHCI 1.3+ включает опциональную поддержку Protection Information. Это связано с невостребованностью функции в системах с SATA дисками и усложнением микрокода для ее реализации.

В NVMe реализация скопирована с SAS и неплохо работает в серверных накопителях, но зачастую зависит от вендора.

Практическая реализация в Linux

Включение простой и эффективной защиты (HBA-generated PI, type 1) на примере SAS SSD и HBA LSI 9300:

sg_format --format --size=(512|4096) --fmtpinfo=2  -vvv /dev/sdX

для HDD занимает от 10 до 40 часов, в зависимости от размера. Размер блока выбираем 512 или 4096, метаданные будут добавлены автоматически (не надо указывать 520b).

(данные на диске будут уничтожены)

Проверка после формата:

sg_readcap -vvv --long /dev/sdX
Read Capacity results:
   Protection: prot_en=1, p_type=0, p_i_exponent=0 [type 1 protection]
   Logical block provisioning: lbpme=1, lbprz=1
   Last LBA=468843605 (0x1bf1fc55), Number of logical blocks=468843606
   Logical block length=4096 bytes
   Logical blocks per physical block exponent=0
   Lowest aligned LBA=0
Hence:
   Device size: 1920383410176 bytes, 1831420.3 MiB, 1920.38 GB

Настройка HBA, как правило, не требуется. Поддержка DIF включена по умолчанию. Проверяется так:

modinfo mpt3sas | egrep -i 'filename|version|parm
…..
parm:           prot_mask: host protection capabilities mask, def=7  (int)
….

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

# lsscsi -p
[0:0:1:0]    disk    SAMSUNG  MZILG1T9HCJR/A07 GXG3  /dev/sdh   -          none
[0:0:2:0]    disk    SAMSUNG  MZILG1T9HCJR/A07 GXG3  /dev/sdi   DIF/Type1  none
[0:0:3:0]    disk    SEAGATE  ST6000NM029A     E003  /dev/sdj   DIF/Type1  none
[0:0:4:0]    disk    SAMSUNG  MZILT1T9HBJR/007 GXA5  /dev/sdk   -          none

Добавление DIF информации происходит абсолютно прозрачно для OS. HBA передает в блочный стэк чистые 512/4096b блоки, добавляет и отрезает чексуммы автоматически.

DIF/DIX — маленькие 8 байт, которые спасают петабайты

DIF/DIX — пример того, как небольшое по размеру поле данных преобразует надёжность всей системы хранения. Это расширение SCSI используется там, где ошибки недопустимы — в банковских и биржевых платформах, SAN хранилищах, критических базах данных и архивах. Многие корпоративные массивы включают PI автоматически и скрывают детали от хоста, но мы теперь знаем :).