我有多路径 IO 配置的服务器 2012 刀片，在 MPIO 路径故障期间显示如下警告：
磁盘 7 的逻辑块地址 0 处的 IO 操作已重试。
我知道是什么导致警告发生，所以我不寻找原因，但这条消息到底是什么意思？
这是否意味着如果此 IO 是一个写操作，那么服务器实际上丢失了它试图写入的数据？
感谢您提供有关此警告消息含义的任何信息。
AskOverflow.Dev
不，这并不意味着数据丢失了。它只是意味着 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 1a2b3c4d5e6f在设备对象的实际地址所在的位置执行操作。然后
kd> dt 0x1a2b3c3c2b1a _CLASS_PRIVATE_FDO_DATA使用您获得的 PrivateFdoData 结构的地址进行操作。现在您已准备好转储从 PrivateFdoData 获得的 AllTransferPacketsList 数据结构。
这个想法是，您正在追踪最后一次看到哪个驱动程序对 IRP 做了什么。如果 IRP 擅离职守时间太长，它就会超时并从头开始重试。这可能是由很多事情引起的……甚至是杂散的宇宙射线。但重要的是事务会从头开始重试，直到IO manager 说完成才算完成。
哦，还有与线程无关的 IO，这是一种完全不同的蠕虫病毒。:)
要进一步阅读此主题，我强烈推荐 Windows Internals 第 6 版的第 8 章 I/O 系统，作者是 Mark Russinovich、Margosis 等人。
**编辑：**我终于找到了这个错误的官方知识库：http: //support.microsoft.com/kb/2819485/EN-US
IO 操作应该重试 8 次，每分钟一次，直到 Windows 放弃。
编辑：如承诺的那样：https ://docs.microsoft.com/en-us/archive/blogs/ntdebugging/interpreting-event-153-errors
不，会有不同的消息，并且（希望）其中一个应用程序层在未能成功保存数据时会抛出异常。
在 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 毫秒）为单位测量。此外，事件中记录了以下值：
BuildIoDuration：MINIPORT 在此请求的构建 I/O 函数中花费 的时间长度StartIoDuration：MINIPORT 在此请求的启动 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
可能是迟到的帖子，但我发现它可能是由 VSS 引起的。我们有一个正在运行 veeam 但忘记关闭 Windows 服务器备份（磁盘已移除）的客户，这导致了一系列问题，而这个错误是主要错误。
停止备份并重击，没有错误。