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

平台

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

功能影响

严重性 - 高
频率 - 高

说明

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

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

  • Windows Microsoft KB 982018 的 982018
  • Windows 7 SP1
  • WindowsServer 2008 R2 with Microsoft KB 982018
  • Windows Server 2008 R2 SP1
  • Windows将 Vista 与 Microsoft KB 2553708
  • WindowsServer 2008 with Microsoft KB 2553708

有关更多详细信息,请参阅有关 Microsoft 支持策略中适用于大型扇区驱动器Windows。

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

逻辑扇区与物理扇区大小

在媒体格式中引入此更改时,其中一个关注点就是与当前市场上提供的软件和硬件的兼容性。 作为一种临时解决方案,存储行业最初引入的磁盘模拟常规的 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 个逻辑扇区) 。

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

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

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

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

避免读-修改-写

虽然某些存储供应商可能会在某些 512e 存储设备中引入某些级别的缓解措施,以尝试并帮助缓解读写周期的性能和复原能力问题,但就工作负荷而言,只能处理太多缓解措施。 因此,应用程序不应依赖此缓解措施作为长期解决方案。

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

问题 1:分区未与物理扇区边界对齐

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

IVdsPack::CreateVolumeIVdsPack2::CreateVolume2 API 在创建新卷时不使用指定的对齐参数,而是使用操作系统 (Pre-Windows Vista SP1 的对齐值默认值将使用 63 个字节,Windows Vista SP1 将使用上述) 中的默认值。 因此,建议需要创建分区的应用程序改为使用 IVdsCreatePartitionEx::CreatePartitionExIVdsAdvancedDisk::CreatePartition API,它们使用指定的对齐参数。

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

问题 2:未缓冲写入与物理扇区大小不一致

基本问题是,未缓冲的写入与存储介质的报告物理扇区大小不一致,从而在驱动器中触发读写操作,从而可能导致性能问题。 另一方面,缓冲写入与页面大小 4 KB 对齐,这恰好是第一代大型扇区介质的物理扇区大小。 但是,具有数据存储大多数应用程序执行无缓冲写入,因此需要确保以物理扇区大小的单位执行这些写入。

为了帮助确定应用程序是否生成未缓冲的 I/O,请在调用 CreateFile 函数时检查 dwFlagsAndAttributes 参数中是否包含 FILE FLAG NO _ _ _ BUFFERING 标志。

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

  • GetDiskFreeSpace、GetDiskFreeSpaceEx
  • FileFsVolumeInformation
  • IOCTL _磁盘 _ 获取 _ 驱动器 _ 几何 图形 ,IOCTL _ 磁盘 _ 获取 _ _ 驱动器几何 _ 图形,例如
  • 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 颁发给任何文件句柄 (必须向) 的卷句柄发出 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 专业人员和你的硬件供应商联系,以讨论大扇区过渡以及它如何影响对你很重要的方案。