通过

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 记录的内容。 以下图表说明了存储设备完成写入所需的步骤：

在 512 字节逻辑扇区中升级 datastor 记录所需的步骤

如上所示，此过程涉及存储设备的一些工作，这可能会导致性能损失。 为了避免此额外工作，必须更新应用程序以执行以下操作：

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

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

复原能力指的是应用程序在会话之间恢复状态的能力。 我们已经了解了 512e 存储设备执行 512 字节扇区写入的必要条件 - 读取-修改-写入循环。 我们来看一看如果覆盖介质上以前的物理扇区的过程被中断会发生什么情况。 后果是什么？

  • 由于大多数硬盘驱动器都会进行就地更新，因此物理扇区（即物理扇区所在的介质部分）可能由于部分覆盖而损坏，导致信息不完整。 换句话说，你可以认为它可能丢失了所有 8 个逻辑扇区（物理扇区逻辑上包含这些扇区）。

  • 虽然大多数具有数据存储的应用程序都设计为具有从介质错误中恢复的能力，但八个扇区的丢失，或者换句话说，八个提交记录的丢失，可能会导致数据存储无法正常恢复。 管理员可能需要从备份中手动还原数据库，甚至可能需要执行漫长的重建。

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

考虑到这一点，应用程序软件必须重新评估代码中做出的任何假设，并注意逻辑和物理扇区大小的区别，以及本文后面讨论的一些有趣的客户场景。

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

避免读取-修改-写入

虽然一些存储供应商可能会在某些 512e 存储设备中引入某些级别的缓解，以尝试缓解读取-修改-写入循环的性能和复原能力问题，但就工作负荷而言，任何缓解措施能够处理的问题也只有这么多。 因此，应用程序不应依赖这种缓解措施作为长期解决方案。

解决这一问题的办法不是驱动器内缓解，而是让应用程序做正确的事情，从而避免读取-修改-写入循环。 本节讨论应用程序可能遇到大型扇区磁盘问题的常见情况，并建议了一种调查途径来尝试解决每个问题。

问题 1：分区与物理扇区边界不一致

当管理员/用户对磁盘进行分区时，可能没有在对齐的边界上创建第一个分区。 这可能会导致所有后续写入与物理扇区边界不对齐。 从 Windows Vista SP1 和 Windows Server 2008 开始，第一个分区位于与 4 KB 物理扇区边界对齐的磁盘（对于 4GB 或更大的磁盘，则是与 64 KB 物理扇区边界对齐）的前 1024 KB。 但是，由于 Windows XP 中的默认分区、第三方分区实用程序或 Windows API 的错误使用的缘故，创建的分区可能无法与物理扇区边界对齐。 开发人员将需要确保使用正确的 API 来帮助确保一致性。 下面概述了用于帮助确保分区对齐的推荐 API。

IVdsPack::CreateVolume 和 IVdsPack2::CreateVolume2 API 在创建新卷时不使用指定的对齐参数，而是使用操作系统的对齐值默认值（Windows Vista SP1 之前的版本将使用 63 个字节，而 Windows Vista SP1 之后的版本将使用上述默认值）。 因此，建议需要创建分区的应用程序改用使用指定对齐参数的 IVdsCreatePartitionEx::CreatePartitionEx 或 IVdsAdvancedDisk::CreatePartition 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

如何查询物理扇区大小

有关演示应用程序如何查询卷的物理扇区大小的代码示例，请参阅 https://msdn.microsoft.com/library/ff800831.aspx。

虽然上述代码示例允许你获取卷的物理扇区大小，但在使用之前，你应该对报告的物理扇区大小进行一些基本的健全性检查，因为据观察，某些驱动程序可能无法返回正确格式的数据：

  • 确保报告的物理扇区大小 >= 报告的逻辑扇区大小。 如果不是，你的应用程序应使用等于报告的逻辑扇区大小的物理扇区大小。
  • 确保报告的物理扇区大小是 2 的幂。 如果不是，你的应用程序应使用等于报告的逻辑扇区大小的物理扇区大小。
  • 如果物理扇区大小是 512 字节到 4 KB 之间的 2 的幂值，则应考虑使用向下舍入到报告的逻辑扇区大小的物理扇区大小。
  • 如果物理扇区大小是大于 4 KB 的 2 的幂值，则在使用该值之前，应评估应用处理这种情况的能力。 否则，应考虑使用向下舍入为 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 专业人员和硬件供应商展开对话，讨论大型扇区转换以及此转换对您的重要场景有何影响。