我有一个配置了多路径 IO 的服务器 2012 刀片，在 MPIO 路径故障期间显示如下警告：
重试了磁盘 7 的逻辑块地址 0 处的 IO 操作。
我知道是什么原因导致了警告的发生，所以我没有寻找原因，但是这个消息实际上意味着什么？
这是否意味着如果此 IO 是写入操作，那么服务器实际上会丢失它尝试写入的数据？
谢谢您对该警告信息含义的阐释。
答案1
不，这并不意味着数据丢失了。这仅仅意味着 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 长时间未执行，则会超时并从头开始重试。这可能是由很多原因造成的……甚至是一条宇宙射线。但重要的是，事务将从头开始重试，并且直到 IO 管理器说它已完成时才会被视为完成。
哦，还有线程无关的 IO，这是一个完全地不同的麻烦。:)
为了进一步了解这个主题，我高度推荐 Mark Russinovich、Margosis 等人撰写的《Windows Internals》第 6 版第 8 章“I/O 系统”。
**编辑：**我终于找到了此错误的官方 KB：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 Server 2012（或 Windows Server 2008 R2 上的修补程序 2819485）之前，当发生这些超时时，系统会默默重试。该消息的目的是提高对这些事件的可见性。它们可能表示容量问题或驱动程序缺陷，对于 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 毫秒) 为单位进行测量。此外，事件中还会记录以下值：
构建Io持续时间：MINIPORT 在此请求的构建 I/O 函数中花费的时间长度 启动Io持续时间：MINIPORT 在此请求的启动 I/O 函数中花费的时间长度 数据传输长度：传输的大小（以字节为单位）
改进 Windows Server 2012 中 Storport.sys 驱动程序日志记录功能的更新
http://support.microsoft.com/kb/2819476
Windows 8 和 Windows Server 2012 累积更新：2013 年 4 月
http://support.microsoft.com/kb/2822241
答案3
可能发帖晚了，但我发现这可能是由 VSS 引起的。我们有一个客户正在运行 veeam，但忘记关闭 windows server 备份（磁盘被移除）这导致了大量问题，而这个错误是主要问题。
停止备份，然后砰，没有错误。