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

平台

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

功能影响

严重性 - 高
频率 - 高

说明

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

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

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

有关更多详细信息,请参阅 有关 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 开始,对于 4GB 或更大的磁盘,第一个分区放置在磁盘 (的前 1024 KB 处,否则对齐为 64 KB) ,与 4 KB 物理扇区边界对齐。 但是,鉴于 Windows XP 中的默认分区、第三方分区实用工具或 Windows API 的不正确用法,创建的分区可能与物理扇区边界不一致。 开发人员需要确保使用正确的 API 来帮助确保一致性。 下面概述了有助于确保分区对齐的建议 API。

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

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

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

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

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

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

  • GetDiskFreeSpaceGetDiskFreeSpaceEx
  • FileFsVolumeInformation
  • IOCTL_DISK_GET_DRIVE_GEOMETRYIOCTL_DISK_GET_DRIVE_GEOMETRY_EX
  • IVdsDisk::GetPropertiesIVdsDisk3::GetProperties2

如何查询物理扇区大小

Microsoft 在 MSDN 上提供了一个代码示例,详细介绍了应用程序如何查询卷的物理扇区大小。 代码示例位于 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 专业人员和硬件供应商进行对话,讨论大型行业转型以及它如何影响对你很重要的方案。