我有多pathIOconfiguration的服务器2012刀片，在MPIOpath故障期间显示如下警告：
重试磁盘7的逻辑块地址0处的IO操作。
我知道是什么导致警告发生，所以我不是在寻找原因，但这个消息实际上是什么意思？
这是否意味着，如果这个IO是一个写操作，那么服务器实际上丢失了它正在尝试写入的数据？
感谢您提供任何关于此警告信息含义的信息。
不，这并不意味着数据丢失了。 这只是表示在IO系统等待完成时，IRP（IO请求数据包）超时，因此再次尝试。 当线程开始任何IO操作时，IOpipe理器创build一个IRP来表示操作在通过系统时的操作。
IRP以初始状态存储在缓冲区/旁路列表中，以便在第一次失败时可以重试。 这提供了人们对任何事务系统的期望，这样我们就可以更加确信你不会把大量损坏或不完整的数据写入你的磁盘。
这个事件在MPIO失败的情况下非常有意义。 说Windows去从SAN存储读取或写入一些东西。 请求被分派，同时，我将其中一条电缆切断到SAN。 该请求永远不会完成，所以Windows将再次尝试请求，只有这一次请求将遵循其他path。
这些事件也会在磁盘负载过重或非常慢时发生。 您可能会注意到这些消息与定时备份等相同。磁盘可能会很慢并且很忙，一些随机的IRP超时，不得不再次尝试。 IRP可能会陷入中断服务程序，或者延期程序调用，或者其他什么。
我可以看到堆栈中有很多IO筛选器驱动程序也加剧了这个问题。
这并不是说这种行为不像以前的Windows版本那样发生，只是微软显然决定在Win8 / Server 2012中显示这些事件。
编辑：你可以用一个内核debugging器find一个线程的优秀的IRP： kd> !irp 1a2b3c4d ，你以前通过发出命令kd> !process 8f7d6c4a来find该地址，该命令将列出所有与该线程相关的IRP处理。 kd> !process 0 0列出所有正在运行的进程。
一旦使用！irp命令列出了关于IRP的信息，就可以很容易地发现哪个驱动程序最后处理了IRP，因为它将在列表中指向它。 然后为了得到关于该驱动程序使用该IRP所做的更多信息，请执行kd> !devobj 1a2b3c4d5e6f ，其中是设备对象的实际地址。
然后使用你得到的kd> dt 0x1a2b3c``3c2b1a _CLASS_PRIVATE_FDO_DATA结构的地址做一个kd> dt 0x1a2b3c``3c2b1a _CLASS_PRIVATE_FDO_DATA 。 （只是一个倒退，我不能让parsing器去做。）
现在，您已经准备好转储您从PrivateFdoData获取的conversionsnsferPacketsList数据结构。
这个想法是，你正在追踪上一次看到的驱动程序与IRP做了什么。 如果IRP太长，它会超时并重新开始。 这可能是由许多事情引起的，甚至是一场stream光溢出的宇宙射线。 但重要的是，交易将从一开始就被重新审视，直到IO经理说这是不完整的。
哦，还有线程无关的IO，这是一个完全不同的蠕虫jar。 🙂
关于这个主题的进一步阅读，我强烈推荐Mark Russinovich，Margosis等人的Windows Internals第6版的第8章I / O系统。
**编辑：**我终于find这个错误的官方KB： 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
不，将会有不同的消息，并且（希望）其中一个应用程序层在未能成功保存数据时会抛出exception。
在Windows Server 2012（或Windows Server 2008 R2上的修补程序2819485）之前，系统会在发生这些超时时以静默方式重试。 该消息的目的是增加这些事件的可见性。 它们可能表示存在容量问题或驱动程序缺陷，对于iSCSI，其他操作系统缺陷可能会导致延迟。
在外部（而不是直接连接）存储的情况下，一些厂商过去增加了超时值，例如60秒。 但是，如果iSCSI启动器等高层组件的默认重试次数已满，则可能意味着在系统启动故障切换之前可能会等待几分钟。 这显然是不理想的行为。
更多信息：
SCSI微型端口驱动程序的registry项
http://msdn.microsoft.com/en-us/library/windows/hardware/ff563970%28v=vs.85%29.aspx
微软发布了一个更新，提供了指定storport.sys操作的阈值的function。
安装此更新后，可以在I / O到存储的等待时间等于或大于阈值时logging一个事件。 阈值可以由用户设置。 此操作在适配器驱动程序级别执行，以便您可以查看SAN上是否存在性能问题。 然后，您可以联系存储供应商来解决该问题。
注意：此更新可恢复Windows 7和Windows Server 2008 R2中提供的function。 启用function时，阈值以100纳秒（0.0001毫秒）为单位进行测量。 此外，在事件中logging下列值：
BuildIoDuration ： MINIPORT在此请求的构buildI / O函数中花费的时间长度StartIoDuration ： MINIPORT在此请求的启动I / O函数中花费的时间长度DataTransferLength ：传输大小（以字节为单位）
更新，提高了Windows Server 2012中Storport.sys驱动程序的日志loggingfunction
http://support.microsoft.com/kb/2819476
Windows 8和Windows Server 2012累积更新：2013年4月
http://support.microsoft.com/kb/2822241
可能是一个晚期的职位，但我发现它可能是由VSS引起的。 我们有一个客户端正在运行veeam，但忘记closuresWindows服务器备份（磁盘被删除）它引起了一个棚子的问题，这个错误是主要的。
停止了回来，并没有错误。