“已重试磁盘 # 的逻辑块地址 # 处的 IO 操作”是什么意思。在 Windows Server System 事件日志中看到时是什么意思?

Chr*_*son 26 mpio windows-server-2012

我有多路径 IO 配置的 server 2012 刀片,在 MPIO 路径故障期间显示如下警告:

磁盘 7 的逻辑块地址 0 处的 IO 操作已重试。

我知道是什么导致警告发生,所以我不是在寻找原因,但这条消息实际上意味着什么?

这是否意味着如果这个 IO 是一个写操作,那么服务器实际上丢失了它试图写的数据?

感谢您提供有关此警告消息含义的任何线索。

Rya*_*ies 34

不,这并不意味着数据丢失。它只是意味着 IRP(IO 请求数据包)在 IO 系统等待它完成时超时,因此再次尝试。当线程开始任何 IO 操作时,IO 管理器会创建一个 IRP 来表示该操作通过系统。

IRP 以初始状态存储在缓冲区/后备列表中,以便在第一次失败时可以重试。这提供了人们期望从任何事务系统中获得的原子性,因此我们可以更加确信您不会将一堆损坏或不完整的数据写入您的磁盘。

在 MPIO 失败的情况下,此事件非常有意义。假设 Windows 开始从 SAN 存储读取或写入某些内容。请求被发送,同时,我切断了连接到 SAN 的一根电缆。该请求永远不会完成,因此 Windows 将再次尝试该请求,只是这次请求将遵循另一条路径。

当磁盘负担过重或非常缓慢时,也会发生这些事件。您可能会注意到这些消息与计划备份等一致。磁盘可能只是缓慢而忙碌,并且一些随机 IRP 超时,不得不重试。IRP 可能陷入中断服务例程、延迟过程调用或其他任何事情。

我可以看到您的堆栈中有很多 IO 过滤器驱动程序也加剧了这个问题。

并不是这种行为在以前版本的 Windows 中没有发生,只是微软显然决定在 Win8/Server 2012 中出现这些事件。

编辑:您可以使用内核调试器找到线程的未完成 IRP:kd> !irp 1a2b3c4d,您之前通过发出命令找到该地址,该命令kd> !process 8f7d6c4a将列出与该进程关联的线程关联的所有 IRP。kd> !process 0 0列出所有正在运行的进程。

一旦您使用 !irp 命令列出有关 IRP 的信息,您就可以很容易地发现上次处理 IRP 的驱动程序,因为>它将在列表中指向它。然后要获得有关该驱动程序使用该 IRP 执行的操作的更多信息,请执行一个kd> !devobj 1a2b3c4d5e6fwhere 是设备对象的实际地址。

然后kd> dt 0x1a2b3c3c2b1a _CLASS_PRIVATE_FDO_DATA使用您获得的 PrivateFdoData 结构的地址进行操作。

现在您已准备好转储从 PrivateFdoData 获得的 AllTransferPacketsList 数据结构。

这个想法是,您正在追踪上次看到 IRP 时驱动程序正在做什么。如果 IRP AWOL 时间过长,则会超时并从头开始重试。这可能是由很多事情引起的……甚至是杂散的宇宙射线。但重要的是,事务会从头开始重试,直到 IO 管理器说完成时才会认为它已完成。

哦,还有与线程无关的 IO,这是一种完全不同的蠕虫。:)

要进一步阅读此主题,我强烈推荐来自 Mark Russinovich、Margosis 等人的 Windows Internals 6th edition 的第 8 章,I/O 系统。

**编辑:**我终于找到了这个错误的官方知识库:http : //support.microsoft.com/kb/2819485/EN-US

IO 操作应该重试 8 次,每分钟一次,直到 Windows 放弃。

编辑:如承诺:https : //docs.microsoft.com/en-us/archive/blogs/ntdebugging/interpreting-event-153-errors

  • 编辑了我的帖子以解决您的后续问题。以后我可能会添加更多信息。 (2认同)
  • 任何可以使用 Windows 调试器来支持他们的观点的人都会在我的书中获得一些荣誉。无法再次对答案进行投票,因此必须对评论进行投票。我有 Windows Internals 6th edition 第 1 部分,我现在准备购买第 8 章的第 2 部分。谢谢 (2认同)

Gre*_*kew 6

不,会有不同的消息,并且(希望)其中一个应用程序层在未能成功保存数据时会抛出异常。

在 Windows Server 2012(或修补程序 2819485,如果在 Windows Server 2008 R2 上)之前,系统将在发生这些超时时静默重试。该消息的目的是提高这些事件的可见性。它们可能表示容量问题或驱动程序缺陷,在 iSCSI 的情况下,其他操作系统缺陷可能归因于延迟。

对于外部(非直连)存储,过去一些供应商已经增加了超时值,例如增加到 60 秒。但是,考虑到更高层组件(例如 iSCSI 启动器)的默认重试次数,这可能意味着在系统启动故障转移之前可能需要几分钟时间。这显然是次优行为。

更多信息:

SCSI 微型端口驱动程序的注册表项
http://msdn.microsoft.com/en-us/library/windows/hardware/ff563970%28v=vs.85%29.aspx

https://docs.microsoft.com/en-us/archive/blogs/san/the-windows-disk-timeout-value-less-is-better


Microsoft 发布了一个更新,该更新提供了为 storport.sys 操作指定阈值的功能。

安装此更新后,您可以在存储 I/O 的延迟时间等于或大于阈值时记录事件。阈值可由用户设置。此操作在适配器驱动程序级别执行,以便您可以查看 SAN 上是否存在性能问题。然后,您可以联系存储供应商来解决该问题。

注意:此更新恢复了 Windows 7 和 Windows Server 2008 R2 中提供的功能。启用该功能后,阈值以 100 纳秒(0.0001 毫秒)为单位进行测量。此外,事件中会记录以下值:

BuildIoDurationMINIPORT在此请求的构建 I/O 函数中花费的时间长度StartIoDurationMINIPORT在此请求 的启动 I/O 函数中花费的时间长度 DataTransferLength:传输的大小(以字节为单位)

改进了 Windows Server 2012 中 Storport.sys 驱动程序日志记录功能的更新
http://support.microsoft.com/kb/2819476

Windows 8 和 Windows Server 2012 累积更新:2013 年 4 月
http://support.microsoft.com/kb/2822241