Поделиться через

Обновление совместимости диска с расширенным форматом (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

Description

Эта статья является обновленной версией статьи под названием 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 Native Disk)
    • VHD и новый формат VHDX-файла
    • Полная поддержка HyperV
    • Программа архивации данных
    • Полная поддержка в файловой системе NT (NTFS)
    • Полная поддержка новых дисковые пространства и пулов (SSP)
    • Полная поддержка в Защитнике Windows
  • Предоставляет новый API для запроса размера физического сектора (FileFsSectorSizeInformation):
    • Доступно для сетевых томов
    • Может быть выдан любой дескриптор файла
    • Доступно для непривилегированных приложений
    • Модель дружественного использования
  • Включает расширенную служебную программу командной строки fsutil для запроса размера тома логического и физического сектора с информацией о выравнивании (базовая версия служебной программы без сведений о выравнивании доступна для Windows 7 с microsoft KB 982018 и Windows Server 2008 R2 с 982018 Microsoft KB).

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

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

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

Начальные типы мультимедиа крупных секторов

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

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

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

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

*За исключением Hyper-V. См. раздел "Требования к поддержке приложений для дисков больших секторов".
Расширенный формат, 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).

Как работает эмуляция: read-modify-write (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) (или microsoft Knowledge Base 982018), эта поддержка распространяется на контроллеры хранилища на основе Storport. Пример кода, показывающий, как приложение может запрашивать размер физического сектора тома, см. в STORAGE_ACCESS_ALIGNMENT_DESCRIPTOR структуре.

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

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

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

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

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

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

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

Проблема 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, как показано ниже.

байты на сектор и на физический сектор диска сектора 4k с эмуляцией 512-байтов

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

байты на сектор и на физический сектор собственного диска 4k

Примечание.

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

Ресурсы