Обновление совместимости дисков с расширенным форматом (4K)

  • Статья

Платформы

Клиентов Windows XP, Windows Vista, Windows 7, Windows 7 с пакетом обновления 1 (SP1), Windows 8
Серверов Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2008 R2 с пакетом обновления 1 (SP1), Windows Server 2012, Windows Server 2012 R2, Windows Server 2016

Описание

Эта статья представляет собой обновленную версию статьи Под названием 512-байтовая эмуляция (512e) Обновление совместимости дисков, выпущенное для Windows 7 с пакетом обновления 1 (SP1) и Windows Server 2008 R2 с пакетом обновления 1 (SP1). Это обновление содержит много новых сведений, некоторые из которых применимы только к Windows 8 и Windows Server 2012.

Плотность площадей увеличивается ежегодно, и с недавним появлением дисков объемом 3 ТБ механизмы исправления ошибок, используемые для борьбы с уменьшением соотношения сигналов к шуму (SNR), становятся неэффективными в пространстве; т. е. для обеспечения удобства использования носителя требуется увеличение объема накладных расходов. Одним из решений отрасли хранения для улучшения этого механизма исправления ошибок является внедрение другого формата физического носителя, который включает в себя больший размер физического сектора. Этот новый физический формат мультимедиа называется Расширенный формат. Таким образом, больше небезопасно делать какие-либо предположения относительно размера сектора современных устройств хранения, и разработчикам потребуется изучить предположения, лежащие в основе их кода, чтобы определить, есть ли это влияние.

В этом разделе описывается влияние устройств хранения расширенного формата на программное обеспечение, рассматриваются возможности приложений для поддержки этого типа носителей, а также рассматривается инфраструктура, которую корпорация Майкрософт представила в Windows Vista, Windows 7 и Windows 8, чтобы разработчики могли поддерживать эти типы устройств. Хотя материалы, представленные в этом разделе, содержат рекомендации по улучшению совместимости с дисками расширенного форматирования, эти сведения обычно применяются ко всем системам с дисками расширенного форматирования под управлением Windows Vista, Windows 7 и Windows 8.

Сводка новых функций, связанных с крупным сектором

В приведенном ниже списке перечислены новые функции, предоставляемые в рамках Windows 8 и Windows Server 2012 для улучшения взаимодействия с клиентами и разработчиками с дисками с большим сектором. Ниже приведено более подробное описание каждого элемента.

  • Основан на поддержке Windows 7 с пакетом обновления 1 (SP1) для дисков размером 4K с эмуляцией (512e) и обеспечивает полную поддержку папки "Входящие" для дисков с размером сектора 4K без эмуляции (4K Native). Ниже перечислены некоторые поддерживаемые приложения и сценарии.
    • Возможность установки Windows и загрузки с диска сектора 4K без эмуляции (собственный диск 4K)
    • VHD и новый формат файлов VHDX
    • Полная поддержка HyperV
    • Резервное копирование Windows
    • Полная поддержка в файловой системе NT (NTFS)
    • Полная поддержка новых дисковые пространства и пулов (SSP)
    • Полная поддержка с помощью Защитник Windows
  • Предоставляет новый API для запроса размера физического сектора (FileFsSectorSizeInformation):
    • Доступно для сетевых томов
    • Может быть выдано для любого дескриптора файла
    • Доступно для непривилегированных приложений
    • Более дружественная модель использования
  • Включает расширенную служебную программу командной строки fsutil для запроса размера логического и физического сектора тома с информацией о выравнивании (базовая версия программы без сведений о выравнивании доступна для Windows 7 с microsoft KB 982018 и Windows Server 2008 R2 с microsoft KB 982018).

Общие сведения о дисках с расширенным форматом (4K)

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

Логический сектор: Единица измерения, используемая для адресации логического блока для носителя. Мы также можем рассматривать его как наименьшую единицу записи, которую может принять хранилище. Это эмуляция.
Физический сектор: Единица измерения, для которой операции чтения и записи на устройстве выполняются за одну операцию. Это единица атомарной записи.
Большинство актуальных API-интерфейсов Windows, таких как IOCTL_DISK_GET_DRIVE_GEOMETRY, возвращают размер логического сектора, но физический размер сектора можно получить с помощью кода элемента управления IOCTL_STORAGE_QUERY_PROPERTY с соответствующими сведениями, содержащимися в поле BytesPerPhysicalSector в структуре STORAGE_ACCESS_ALIGNMENT_DESCRIPTOR . Более подробно это рассматривается далее в этой статье.

Начальные типы носителей больших секторов

Отрасль хранения быстро наращивает усилия по переходу на этот новый тип хранилища расширенного формата для носителей с размером физического сектора 4 КБ. На рынок будут выпущены два типа средств массовой информации:

4 КБ в собственном коде: Этот носитель не имеет слоя эмуляции и напрямую предоставляет 4 КБ в качестве размера логического и физического сектора. Общая проблема с этим новым типом носителей заключается в том, что большинство приложений и операционных систем не запрашивают и не сопоставляют операции ввода-вывода с размером физического сектора, что может привести к непредвиденным сбоям ввода-вывода.
512-байтовая эмуляция (512e): Этот носитель имеет уровень эмуляции, как описано в предыдущем разделе, и предоставляет 512 байт в качестве размера логического сектора (аналогично обычному диску сегодня), но делает доступными сведения о размере физического сектора (4 КБ). Общая проблема с этим новым типом носителей заключается в том, что большинство приложений и операционных систем не понимают существование размера физического сектора, что может привести к ряду проблем, как будет рассмотрено ниже.
Общая поддержка Windows для больших секторов мультимедиа

В этой таблице описана официальная политика поддержки Майкрософт для различных средств массовой информации и их размеры секторов. Дополнительные сведения см. в этой статье базы знаний .

Общие имена Размер сообщаемого логического сектора Размер физического сектора, сообщаемого Версия Windows с поддержкой
512-байтный машинный код, 512n 512 байт 512 байт Все версии Windows
Расширенный формат, 512e, AF, 512-байтовая эмуляция 512 байт 4 КБ Windows Vista с ms kb 2553708
Windows Server 2008* w/ MS KB 2553708
Windows 7 с ms kb 982018
Windows Server 2008 R2* w/ MS KB 982018
Все версии Windows 7 с пакетом обновления 1 (SP1) и более поздних версий.
Все версии Server 2008 R2 с пакетом обновления 1 (SP1) и более поздних версий.

*За исключением Hyper-V. См. раздел "Требования к поддержке приложений для дисков с большим сектором".
Advance Format, AF, 4K Native, 4Kn 4 КБ 4 КБ Все версии Windows Windows 8 и более поздних версий
Все версии сервера Windows Server 2012 и более поздних версий
Другое Не 4 КБ или 512 байт Не 4 КБ или 512 байт Не поддерживается

Примечание

Хотя в предыдущей таблице не подчеркнуто, Windows XP, Windows Server 2003 и Windows Server 2003 R2 не поддерживают носители 512e или 4Kn. Хотя система может загружаться и работать в минимальном режиме, возможны неизвестные сценарии проблем с функциональностью, потери данных или неоптимальной производительности. Таким образом, корпорация Майкрософт настоятельно предостерегает от использования 512e-носителей с Windows XP или других продуктов на основе базы кода Windows XP (таких как Windows Home Server 1.0, Windows Server 2003, Windows Server 2003 R2, Windows XP 64-разрядная версия, Windows XP Embedded, Windows Small Business Server 2003 и Windows Small Business Server 2003 R2).

Принцип работы эмуляции: чтение, изменение и запись (RMW)

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

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

шаги для завершения записи на запоминающее устройство

Как показано выше, этот процесс включает определенную работу запоминающего устройства, которая может привести к снижению производительности. Чтобы избежать этой дополнительной работы, приложения должны быть обновлены до следующего:

  • Запрос размера физического сектора
  • Убедитесь, что операции записи соответствуют размеру физического сектора.

Хотя изначально может показаться, что это только проблема с производительностью, может возникнуть более серьезная проблема. Давайте обсудим это в следующем разделе.

Устойчивость: скрытые затраты на чтение, изменение и запись

Устойчивость говорит о способности приложения восстанавливать состояние между сеансами. Мы увидели, что необходимо для устройства хранения 512e для выполнения 512-байтовой записи в секторе цикла чтения, изменения и записи. Давайте посмотрим, что произойдет, если прервется процесс перезаписи предыдущего физического сектора на носителе. Каковы будут последствия?

  • Поскольку большинство жестких дисков обновляются на месте, физический сектор, т. е. часть носителя, на которой был расположен физический сектор, могла быть повреждена с неполными сведениями из-за частичной перезаписи. Другими словами, вы можете думать о нем как о потенциальной потере всех 8 логических секторов (которые физический сектор логически содержит).
  • Хотя большинство приложений с хранилищем данных разработаны с возможностью восстановления после ошибок мультимедиа, потеря восьми секторов или, другими словами, потеря восьми записей фиксации потенциально может сделать невозможным для хранилища данных корректное восстановление. Администратору может потребоваться вручную восстановить базу данных из резервной копии или даже выполнить длительную перестройку.
  • Еще один важный эффект заключается в том, что действие другого приложения, вызывающее цикл чтения, изменения и записи, может привести к потере данных, даже если приложение не работает! Это просто потому, что данные и данные другого приложения могут находиться в одном физическом секторе.

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

Поступая правильно (избегая чтения, изменения и записи)

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

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

Проблема 1. Секция не выровнена по границе физического сектора

Когда администратор или пользователь секционирует диск, первый раздел может не быть создан на выровненной границе. Это может привести к тому, что все последующие операции записи не будут выровнены к границам физического сектора. В Windows Vista с пакетом обновления 1 (SP1) и Windows Server 2008 первый раздел помещается в первые 1024 КБ диска (для дисков размером 4 ГБ или больше, в противном случае выравнивание составляет 64 КБ), что соответствует границе физического сектора размером 4 КБ. Однако, учитывая секционирование по умолчанию в Windows XP, сторонней программе секционирования или неправильном использовании API Windows, созданные секции могут быть не выровнены по границам физического сектора. Разработчикам потребуется убедиться, что для обеспечения выравнивания используются правильные API. Ниже приведены рекомендуемые API для обеспечения выравнивания секций.

API IVdsPack::CreateVolume и IVdsPack2::CreateVolume2 не используют указанный параметр выравнивания при создании нового тома, а используют значение выравнивания по умолчанию для операционной системы (предварительная версия Windows Vista с пакетом обновления 1 (SP1) будет использовать 63 байта, а после Windows Vista с пакетом обновления 1 (SP1) — указанные выше значения по умолчанию. Вместо этого используйте API IVdsCreatePartitionEx::CreatePartitionEx или IVdsAdvancedDisk::CreatePartition, которые используют указанный параметр выравнивания для тех приложений, которым необходимо создать секции.

Лучший способ убедиться в правильности выравнивания — правильно сделать это при первоначальном создании секции. В противном случае приложение должно учитывать выравнивание при выполнении операций записи или при инициализации, что может быть очень сложным процессом.

Проблема 2. Необученные операции записи не соответствуют размеру физического сектора

Самая простая проблема заключается в том, что операции записи без буфера не соответствуют размеру физического сектора носителя. Буферизация операций записи, с другой стороны, выравнивается по размеру страницы 4 КБ, что по совпадению является размером физического сектора первого поколения носителей больших секторов. Однако большинство приложений с хранилищем данных выполняют небуферизованные операции записи, поэтому им необходимо обеспечить выполнение этих операций в единицах физического сектора.

Некоторые примеры сценариев, в которых результирующий ввод-вывод приложения является несогласованным:

Записи фиксации заполняются 512-байтными секторами: Приложения с хранилищем данных обычно имеют определенную форму записи фиксации, которая либо хранит сведения об изменениях метаданных, либо поддерживает структуру хранилища данных. Чтобы гарантировать, что потеря сектора не влияет на несколько записей, эта запись фиксации обычно заполняется до размера сектора. При использовании диска с большим размером физического сектора приложению потребуется запросить размер физического сектора, как показано в предыдущем разделе, и обеспечить заполнение каждой записи фиксации до этого размера. При использовании диска 4K это гарантирует, что операции ввода-вывода не завершаются сбоем. При использовании диска 512e это не только позволяет избежать цикла чтения, изменения и записи, но и гарантирует, что при потере физического сектора будет потеряна только одна запись фиксации.
Файлы журналов записываются в неуправляемые блоки: Небуферированные операции ввода-вывода обычно используются при обновлении или добавлении в файл журнала. Приложения могут переключаться на буферизацию операций ввода-вывода или внутренне буферигрировать обновления журналов в единицах физического сектора, чтобы избежать сбоя ввода-вывода или активации операции чтения, изменения и записи.
Чтобы определить, возникают ли проблемы с небуферизованным вводом-выводом в приложении, обязательно включите флаг FILE_FLAG_NO_BUFFERING в параметр dwFlagsAndAttributes при вызове функции CreateFile.

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

  • GetDiskFreeSpace, GetDiskFreeSpaceEx
  • FileFsVolumeInformation
  • IOCTL_DISK_GET_DRIVE_GEOMETRY, IOCTL_DISK_GET_DRIVE_GEOMETRY_EX
  • IVdsDisk::GetProperties, IVdsDisk3::GetProperties2

Вот как можно запросить размер физического сектора:

Предпочтительный метод для Windows 8

С Windows 8 корпорация Майкрософт представила новый API, который позволяет разработчикам легко интегрировать поддержку 4K в свои приложения. Этот новый API поддерживает еще большее количество сценариев, чем устаревший метод для Windows Vista и Windows 7, рассмотренный ниже. Этот API позволяет выполнять следующие сценарии вызова:

  • Вызов из непривилегированного приложения
  • Вызов любого допустимого дескриптора файла
  • Вызов дескриптора файла на удаленном томе по протоколу SMB2
  • Упрощенная модель программирования

API имеет форму нового информационного класса FileFsSectorSizeInformation со связанной структурой FILE_FS_SECTOR_SIZE_INFORMATION, определяемой следующим образом:

typedef struct _FILE_FS_SECTOR_SIZE_INFORMATION {  
    ULONG LogicalBytesPerSector;  
    ULONG PhysicalBytesPerSectorForAtomicity;  
    ULONG PhysicalBytesPerSectorForPerformance;  
    ULONG FileSystemEffectivePhysicalBytesPerSectorForAtomicity;  
    ULONG Flags;  
    ULONG ByteOffsetForSectorAlignment;  
    ULONG ByteOffsetForPartitionAlignment;  
} FILE_FS_SECTOR_SIZE_INFORMATION, *PFILE_FS_SECTOR_SIZE_INFORMATION;

Устаревший метод для Windows 7 и Windows Vista

В Windows Vista и Windows Server 2008 появились API для запроса размера физического сектора подключенного запоминающего устройства для контроллеров хранения на основе AHCI. В Windows 7 и Windows Server 2008 R2 с пакетом обновления 1 (SP1) (или 982018 базы знаний Майкрософт) эта поддержка распространяется на контроллеры хранения на основе Storport. Корпорация Майкрософт предоставила пример кода на сайте MSDN с подробными сведениями о томе, как приложение может запрашивать размер физического сектора тома.

Хотя приведенный выше пример кода позволяет получить размер физического сектора тома, перед использованием необходимо выполнить базовую проверку работоспособности указанного размера физического сектора, так как было замечено, что некоторые драйверы могут возвращать неправильно отформатированные данные:

  • Убедитесь, что указанный размер физического сектора равен >указанному размеру логического сектора. В противном случае приложение должно использовать размер физического сектора, равный указанному размеру логического сектора.
  • Убедитесь, что указанный размер физического сектора равен двум; Если это не так, приложение должно использовать физический размер сектора, равный указанному размеру логического сектора.
  • Если размер физического сектора равен двум значениям от 512 байт до 4 КБ, рекомендуется использовать размер физического сектора, округленный до указанного размера логического сектора.
  • Если размер физического сектора равен двум значениям, превышающим 4 КБ, перед использованием этого значения следует оценить способность приложения к обработке этого сценария. В противном случае рекомендуется использовать размер физического сектора, округленный до 4 КБ.

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

  • Требует повышенных привилегий; Если приложение не работает с привилегиями, может потребоваться написать приложение-службу Windows, как указано выше.
  • Не поддерживает тома SMB; Вам также может потребоваться написать приложение-службу Windows для поддержки запросов к размеру физического сектора на этих томах
  • Не может быть выдан ни одному дескриптору файла (IOCTL должен быть выдан дескриптору тома)

Проблема 3. Форматы файлов, основанные на 512-байтовых секторах

Некоторые приложения со стандартными форматами файлов (например, VHD 1.0) могут жестко запрограммировать эти файлы, чтобы предположить размер сектора 512 байт. Таким образом, обновление и запись в этот файл приведет к циклу чтения, изменения и записи на устройстве, что потенциально приведет к проблемам с производительностью и устойчивостью для ваших клиентов. Однако существуют способы, которыми приложение может обеспечить поддержку работы с этим типом носителей, например:

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

Проблема 4. Указанный размер физического сектора может меняться между сеансами

Существует множество сценариев, в которых размер физического сектора базового хранилища, в котором размещается Datastor, может измениться. Наиболее распространенные из них — перенос datastor на другой том или даже по сети. Изменение размера физического сектора может быть неожиданным событием для многих приложений и может привести к тому, что некоторые приложения не смогут повторно инициализироваться.

Это не самый простой сценарий для поддержки, и он упоминается здесь в качестве рекомендации. Следует учитывать требования клиентов к мобильности и соответствующим образом настраивать поддержку, чтобы гарантировать, что использование собственных носителей 4K или 512e не повлияет на клиентов.

Как пользователь может получить размер логического и физического сектора для тома

В комплекте с Windows — это служебная программа для отображения сведений о размере сектора для тома. Ниже перечислены версии Windows с поддержкой fsutil.

  • Windows 8
  • Windows Server 2012
  • Windows 7 с пакетом обновления 1 (SP1) с microsoft KB 982018
  • Windows 7 с microsoft KB 982018
  • Windows Server 2008 R2 с пакетом обновления 1 (SP1) с microsoft KB 982018 (версия 3)
  • Windows Server 2008 R2 с microsoft KB 982018 (версия 3)
  • Windows Vista с microsoft KB 2553708
  • Windows Server 2008 с microsoft KB 2553708

Чтобы получить сведения о размере сектора, вызовите служебную программу следующим образом из командной строки с повышенными привилегиями:

fsutil fsinfo ntfsinfo <drive letter>

Для диска сектора 4K с эмуляцией 512 байт поле "Байт на сектор" имеет значение 512, а для поля "Байт на физический сектор" — 4096 следующим образом:

байт на сектор и на физический сектор диска объемом 4 КБ с эмуляцией 512 байт

Собственный диск размером 4K имеет поля Байт на сектор и Байт на физический сектор, как задано значение 4096, как показано ниже.

байт на сектор и физический сектор собственного диска размером 4 КБ

Примечание

Если в поле Byte Per Physical Sector (Байт на физический сектор) отображается значение Не поддерживается, то драйвер хранилища не поддерживает IOCTL_STORAGE_QUERY_PROPERTY или произошла ошибка при получении сведений.

Ресурсы