512 字节仿真 (512e) 磁盘兼容性更新

  • 项目

平台

客户端 - Windows Vista、Windows 7、Windows 7 SP1
服务器 - Windows Server 2008、Windows Server 2008 R2、Windows Server 2008 R2 SP1

功能影响

严重性 - 高
频率 - 高

说明

平均密度逐年增加，随着 3 TB 磁盘的出现，用于处理信号与噪声比率下降 (SNR) 的错误更正机制正在变得空间效率低下-也就是说，确保媒体可用所需的开销增加。 用于改进此错误更正机制的存储行业解决方案之一是引入不同的物理媒体格式，其中包括更大的物理扇区大小。 这种新的物理媒体格式称为 “高级格式”。 因此，就现代存储设备的扇区大小做出任何假设不再安全，开发人员需要研究其代码基础的假设，以确定是否有影响。

本主题介绍高级格式存储设备对软件的影响，讨论应用程序可执行的操作来帮助支持此类媒体，并讨论使开发人员能够支持这些类型的设备的基础结构。 虽然本主题中介绍的材料提供了改进与高级格式磁盘兼容性的指南，但信息通常适用于具有高级格式磁盘的所有系统。 以下版本的Windows为查询物理扇区大小提供支持：

  • 使用 Microsoft KB 982018 Windows 7
  • Windows 7 SP1
  • 使用 Microsoft KB 982018 Windows Server 2008 R2
  • Windows Server 2008 R2 SP1
  • 使用 Microsoft KB 2553708 Windows Vista
  • 使用 Microsoft KB 2553708 Windows Server 2008

有关其他详细信息，请参阅有关 Windows 中大型扇区驱动器的 Microsoft 支持策略的信息。

有关高级格式磁盘的详细信息，请联系存储供应商。

逻辑扇区大小与物理扇区大小

在媒体格式引入这种更改时，其中一个担忧是与目前市场上目前可用的软件和硬件兼容。 作为临时解决方案，存储行业最初引入了模拟常规 512 字节扇区磁盘的磁盘，但通过标准 ATA 和 SCSI 命令提供有关真实扇区大小的信息。 由于此仿真，有两个扇区大小：

  • 逻辑扇区：用于媒体的逻辑块寻址的单元。 我们还可以将它视为存储可以接受的最小写入单元。 这是模拟。

  • 物理扇区：在单个操作中完成对设备的读取和写入操作的单元。 这是原子写入的单元。

大多数最新的Windows API（如IOCTL_DISK_GET_DRIVE_GEOMETRY）将返回逻辑扇区大小，但可以通过IOCTL_STORAGE_QUERY_PROPERTY控制代码检索物理扇区大小，并在STORAGE_ACCESS_ALIGNMENT_DESCRIPTOR结构中的 BytesPerPhysicalSector 字段中包含相关信息。 本文稍后将更详细地讨论这一点。

大型扇区媒体的初始类型

存储行业正在迅速加大力度，以过渡到这种具有 4 KB 物理扇区大小的媒体的新高级格式存储类型。 两种类型的媒体将发布到市场：

  • 4 KB 本机：此媒体没有仿真层，直接公开 4 KB 作为其逻辑扇区大小和物理扇区大小。 Windows和其他大多数操作系统当前不支持此媒体。 但是，Microsoft 正在调查在未来版本的Windows中支持此类媒体的可行性，并在适当时发布知识库文章。
  • 512 字节仿真 (512e) ：此媒体具有上一部分中讨论的仿真层，并将 512 字节公开为其逻辑扇区大小， (类似于当前常规磁盘) ，但使其物理扇区大小信息 (4 KB) 可用。 这是几个存储供应商目前正在向市场引入的内容。 这种新型媒体的总体问题是，大多数应用程序和操作系统都不知道物理扇区大小的存在，这可能会导致许多问题，如下所述。

仿真的工作原理：读取-修改-写入 (RMW)

存储介质具有可以修改物理介质的特定单元。 也就是说，媒体只能以物理扇区大小的单位编写或重写。 因此，不在此单元级别执行的写入需要执行其他步骤，我们将在以下示例中演练这些步骤。

在此方案中，应用程序需要更新位于 512 字节逻辑扇区内的 Datastor 记录的内容。 下图演示了存储设备完成写入所需的步骤：

steps needed to upgrade datastor record within a 512-byte logical sector

如上所述，此过程涉及存储设备的一些工作，可能会导致性能损失。 若要避免此附加工作，必须更新应用程序才能执行以下操作：

  • 查询物理扇区大小。
  • 确保写入与报告的物理扇区大小保持一致。

读取-修改-写入的复原能力影响

复原能力说明了应用程序在会话之间恢复状态的能力。 我们已经了解了 512e 存储设备执行 512 字节扇区写入所需的内容 - 读取-修改-写入周期。 让我们看看，如果媒体上覆盖以前的物理扇区的过程中断，会发生什么情况。 后果是什么？

  • 由于大多数硬盘驱动器都已就位，因此物理扇区（即物理扇区所在的媒体部分）可能由于部分覆盖而损坏了不完整的信息。 换句话说，可以将它视为可能丢失所有 8 个逻辑扇区， (物理扇区逻辑上包含) 。

  • 虽然具有数据存储的大多数应用程序都设计为能够从媒体错误中恢复、丢失 8 个扇区或采用另一种方式，但丢失 8 个提交记录可能会使数据存储无法正常恢复。 管理员可能需要从备份手动还原数据库，甚至可能需要执行长时间的重新生成。

  • 另一个重要影响是，另一个应用程序的行为会导致读取-修改-写入周期可能导致数据丢失，即使应用程序未运行！ 这仅仅是因为你的数据和其他应用程序的数据可以位于同一物理扇区中。

考虑到这一点，应用程序软件必须重新评估代码中采用的任何假设，并了解逻辑物理扇区大小差异，以及本文后面讨论的一些有趣的客户方案。

如果应用程序依赖于日志结构数据存储，则更有可能出现此问题。

避免读取-修改-写入

虽然某些存储供应商可能会在某些 512e 存储设备中引入一些级别的缓解措施，以帮助缓解读写周期的性能和复原能力问题，但工作负载方面只能处理这么多缓解措施。 因此，应用程序不应将此缓解作为长期解决方案。

此解决方案不是驱动器内缓解，而是让应用程序执行正确的一组操作，以避免读取-修改-写入周期。 本部分讨论应用程序在大型扇区磁盘上可能存在问题的常见方案，并建议一种调查途径来尝试并解决每个问题。

问题 1：分区不与物理扇区边界对齐

当管理员/用户对磁盘进行分区时，可能尚未在对齐边界上创建第一个分区。 这可能会导致所有后续写入与物理扇区边界不对齐。 从 Windows Vista SP1 和 Windows Server 2008 开始，第一个分区放置在磁盘 4GB 或更大的磁盘 (的前 1024 KB，否则对齐方式为 64 KB) ，与 4 KB 物理扇区边界对齐。 但是，鉴于 Windows XP 中的默认分区，第三方分区实用工具或Windows API 的使用不正确，创建的分区可能无法与物理扇区边界对齐。 开发人员需要确保使用正确的 API 来帮助确保对齐。 建议的 API 有助于确保分区对齐方式如下所述。

创建新卷时，IVdsPack：：CreateVolume 和 IVdsPack2：：CreateVolume2 API 不使用指定的对齐参数，而是使用操作系统的对齐值默认值， (预Windows Vista SP1 将使用 63 字节，帖子 Windows Vista SP1 将使用上述默认值) 。 因此，建议需要创建分区的应用程序使用 IVdsCreatePartitionEx：：CreatePartitionEx 或 IVdsAdvancedDisk：：CreatePartition API，而该 API 使用指定的对齐参数。

帮助确保对齐正确的最佳方式是在最初创建分区时正确执行。 否则，应用程序需要在执行写入或初始化时考虑对齐方式，这可能是一个非常复杂的问题。 从 Windows Vista SP1 开始，这通常不是问题;但是，较旧版本的Windows可以创建未对齐的分区，这可能会导致某些高级格式磁盘的性能问题。

问题 2：未调整写入与物理扇区大小不一致

基本问题是，未压缩的写入与存储介质的报告物理扇区大小不一致，这会在驱动器中触发可导致性能问题的读-修改写入。 另一方面，缓冲写入与页面大小（4 KB）对齐，巧合的是第一代大型扇区媒体的物理扇区大小。 但是，具有数据存储的大多数应用程序执行无缓冲区写入，因此需要确保以物理扇区大小的单位执行这些写入。

若要帮助确定应用程序是否发出无缓冲区 I/O，请检查在调用 CreateFile 函数时是否在 dwFlagsAndAttributes 参数中包含FILE_FLAG_NO_BUFFERING标志。

此外，如果当前将写入与扇区大小对齐，则此扇区大小很可能只是 逻辑 扇区大小，因为查询媒体扇区大小的大多数现有 API 实际上只是查询寻址单位（即逻辑扇区大小）。 此处感兴趣的扇区大小是物理扇区大小，这是原子性的实际单位。 检索逻辑扇区大小的 API 的一些示例包括：

  • GetDiskFreeSpace、 GetDiskFreeSpaceEx
  • FileFsVolumeInformation
  • IOCTL_DISK_GET_DRIVE_GEOMETRY、 IOCTL_DISK_GET_DRIVE_GEOMETRY_EX
  • IVdsDisk：：GetProperties、 IVdsDisk3：：GetProperties2

如何查询物理扇区大小

Microsoft 在 MSDN 上提供了一个代码示例，详细说明了应用程序如何查询卷的物理扇区大小。 代码示例位于 https://msdn.microsoft.com/library/ff800831.aspx.

虽然上面的代码示例允许你获取卷的物理扇区大小，但应先对报告的物理扇区大小执行一些基本理智检查，因为观察到某些驱动程序可能无法返回格式正确的数据：

  • 确保报告的物理扇区大小为 >= 报告的逻辑扇区大小。 如果不是，应用程序应使用等于所报告逻辑扇区大小的物理扇区大小。
  • 确保报告的物理扇区大小为 2 的幂。 如果不是，应用程序应使用等于所报告逻辑扇区大小的物理扇区大小。
  • 如果物理扇区大小是介于 512 字节和 4 KB 之间的两个幂值，应考虑使用将物理扇区大小舍入到报告的逻辑扇区大小。
  • 如果物理扇区大小是大于 4 KB 的两个幂值，则应在使用该值之前评估应用程序处理此方案的能力。 否则，应考虑使用将物理扇区大小舍入为 4 KB。

使用此 IOCTL 获取物理扇区大小确实存在一些限制：

  • 需要提升的权限。 如果应用程序未以特权运行，则可能需要按照上述所述编写Windows服务应用程序。

  • 不支持 SMB 卷。 可能还需要编写Windows服务应用程序以支持对这些卷进行物理扇区大小查询。

  • 无法向任何文件句柄颁发， (必须将 IOCTL 颁发给卷句柄) 。

  • 仅在本文开头附近列出的Windows版本中受支持。

提交记录填充到 512 字节扇区

具有数据存储的应用程序通常具有某种形式的提交记录，这些记录可以维护有关元数据更改的信息或维护数据存储的结构。 为了确保扇区丢失不会影响多个记录，此提交记录通常填充为扇区大小。 对于具有较大物理扇区大小的磁盘，应用程序需要查询物理扇区大小，如上一部分所示，并确保将每个提交记录填充到该大小。 这不仅避免了读取-修改-写入周期，还有助于确保在物理扇区丢失的情况下，只会丢失一个提交记录。

日志文件以未对齐的区块写入

更新或追加日志文件时，通常会使用无缓冲区 I/O。 有多种方法可帮助确保这些更新正确对齐：

  • 内部缓冲对操作介质的物理扇区大小的更新，并且仅在物理扇区单元已满时发出日志写入
  • 使用缓冲 I/O

问题 3：依赖于 512 字节扇区的文件格式

某些采用标准文件格式的应用程序 (（例如 VHD 1.0) ）可能会硬编码这些文件，以假定扇区大小为 512 字节。 因此，对此文件的更新和写入将导致设备上的读取-修改-写入周期，这可能会导致客户的性能和复原能力问题。 但是，应用程序可通过多种方式提供对此类媒体上操作的支持，例如：

  • 使用缓冲来确保以物理扇区大小的单位执行写入
  • 实现内部读取-修改-写入，以帮助确保按所报告物理扇区大小的单位执行更新
  • 如果可能，填充记录到物理扇区，这样填充就会被解释为空空间
  • 考虑重新设计新版本的应用程序数据结构，以支持更大的扇区

问题 4：报告的物理扇区大小可以在会话之间更改

许多情况下，承载 Datastor 的基础存储的报告的物理扇区大小可能会更改。 最常见的是将 Datastor 迁移到另一个卷，甚至跨网络。 报告的物理扇区大小的更改可能是许多应用程序的意外事件，可能会导致某些应用程序甚至无法重新初始化。

这不是最容易支持的方案，此处将作为公告提及。 应考虑客户的移动性要求，并相应地调整支持，以帮助确保客户不会受到 512e 媒体的负面影响。

4 KB 本机媒体

512 字节仿真介质是指 512 字节本机媒体和 4 KB 本机媒体之间的过渡步骤，预计 512e 后不久将发布 4 KB 本机媒体。 此媒体有几个重要影响，应指出：

  • 逻辑扇区大小和物理扇区大小均为 4 KB
  • 由于没有仿真层，因此存储将失败未对齐的写入
  • 没有隐藏的复原能力命中 - 应用程序要么工作，要么不起作用

尽管 Microsoft 目前正在调查在将来版本的Windows中对这些类型的媒体的支持，并在适当时发布知识库文章，但应用程序开发人员应考虑先发制人地为这些类型的媒体提供支持。

关闭

在本文中，我们讨论了大型扇区媒体在许多常见部署方案中引入的影响。 我们看到了读-修改-写的性能和复原能力影响、此媒体可以引入的一些有趣的方案，以及它们可能对软件造成的问题集，最终会影响最终用户。 存储行业正在迅速过渡到具有较大扇区大小的媒体，很快客户将无法购买具有传统 512 字节扇区大小的磁盘。

这是一个活生生的文档，旨在帮助开发人员了解这种过渡。 应开始与各自的组织、客户、IT 专业人员和硬件供应商进行对话，讨论大型行业过渡以及它如何影响对你至关重要的方案。