Обновление для совместимости за счет эмуляции дисков с 512-байтовыми секторами (512e)

  • Статья

Платформа

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

Влияние на функции

Уровень серьезности — высокий
Частота — высокая

Описание

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

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

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

Дополнительные сведения см. в статье Сведения о политике поддержки Майкрософт для дисков с большим сектором в Windows.

Для получения дополнительных сведений о дисках расширенного форматирования обратитесь к поставщику хранилища.

Логический и физический размер сектора

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

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

  • Физический сектор: единица, для которой операции чтения и записи на устройстве выполняются за одну операцию. Это единица атомарной записи.

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

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

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

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

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

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

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

шаги, необходимые для обновления записи хранилища данных в 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 , которые используют указанный параметр выравнивания.

Лучший способ обеспечить правильность выравнивания — правильно сделать это при первоначальном создании секции. В противном случае приложению потребуется учитывать выравнивание при выполнении операций записи или инициализации, что может быть очень сложным вопросом. В Windows Vista с пакетом обновления 1 (SP1) это, как правило, не является проблемой; Однако более старые версии Windows могут создавать несровненные секции, что может привести к проблемам с производительностью некоторых дисков расширенного форматирования.

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

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

Чтобы определить, возникают ли проблемы с небуферизованным вводом-выводом в приложении, проверка включить флаг 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

Запрос размера физического сектора

Корпорация Майкрософт предоставила пример кода на сайте MSDN с подробными сведениями о том, как приложение может запрашивать размер физического сектора тома. Пример кода находится по адресу https://msdn.microsoft.com/library/ff800831.aspx.

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

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

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

  • Требуются повышенные привилегии. Если приложение не выполняется с привилегиями, может потребоваться написать приложение-службу Windows, как указано выше.

  • Не поддерживает тома SMB. Вам также может потребоваться написать приложение-службу Windows для поддержки запросов к размеру физического сектора на этих томах.

  • Не может быть выдан ни одному дескриптору файла (IOCTL должен быть выдан дескриптору тома).

  • Поддерживается только в версиях Windows, перечисленных в начале этой статьи.

Записи фиксации заполняются 512-байтными секторами

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

Файлы журналов записываются в несгруппированные блоки

Небуферизованный ввод-вывод обычно используется при обновлении или добавлении в файл журнала. Существует несколько способов обеспечить правильное выравнивание этих обновлений.

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

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

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

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

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

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

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

4 КБ собственного носителя

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

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

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

Закрытие

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

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