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


22

我已将多路径IO配置为Server 2012刀片,在MPIO路径故障期间显示如下警告:

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

我知道引起警告发生的原因是什么,所以我不在寻找原因,但是此消息实际上是什么意思?

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

感谢您对本警告消息的含义有所了解。

Answers:


28

不,这并不意味着数据丢失。这仅表示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是AWOL的时间过长,则会超时并从头开始重试。这可能是由很多东西引起的,甚至是宇宙射线。但是重要的是,从一开始就将重试该事务,直到IO经理说是可以完成之后,该事务才被视为已完成。

哦,还有与线程无关的IO,它是完全不同的蠕虫病毒。:)

为了进一步阅读该主题,我强烈建议Windows内幕第六版的第8章,I / O系统,来自Mark Russinovich,Margosis等人。

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

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

编辑:按照承诺:http//blogs.msdn.com/b/ntdebugging/archive/2013/04/30/interpreting-event-153-errors.aspx


1
谢谢Ryan,我希望这意味着该请求已退休,但数据并未丢失,并且将创建另一个请求以尝试再次写入数据。您是否可以引用任何答案源(书籍,文章,说明您可以访问Windows源代码,因为您是个庞大的EA客户,并且进行了调试跟踪以查找此信息,等等)?我想进一步了解这一点。
克里斯·马格努森

2
编辑了我的帖子,以解决您的后续问题。以后我可能会提供更多信息。
瑞安·里斯

2
任何可以使用Windows调试器支持其观点的人都可以在我的书中赢得一些赞誉。无法再次投票给答案,因此必须评论。我拥有Windows Internals 6th Edition第1部分,现在我要购买第8章的第2部分。谢谢
克里斯·马格努森


6

不,会有不同的消息,并且(希望)如果应用程序层之一未能成功保存数据,则会抛出异常。

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

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

更多信息:

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

https://blogs.msdn.com/b/san/archive/2011/09/01/the-windows-disk-timeout-value-understanding-why-this-should-be-set-to-a-small- value.aspx


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


4

可能是较晚的帖子,但我发现它可能是由VSS引起的。我们有一个正在运行veeam的客户端,但是忘记了关闭Windows服务器备份(磁盘已删除),这导致了很多问题,而这个错误是主要的错误。

停止了备份,没有任何错误。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.