Windows Serverシステムイベントログに表示される「IO Disk＃の論理ブロックアドレス＃での操作が再試行されました。」とはどういう意味ですか？
マルチパスIO構成されたサーバー2012ブレードがあり、MPIOパスの障害時に次のような警告が表示されます。
ディスク7の論理ブロックアドレス0でのIO操作が再試行されました。
警告が発生する原因を知っているので原因を探していませんが、このメッセージは実際にはどういう意味ですか？
これがIO=書き込み操作であった場合、サーバーが実際に書き込みしようとしたデータを失ったことを意味しますか？
この警告メッセージの意味に当てはまる光をありがとう。
いいえ、データが失われたという意味ではありません。これは、IOシステムが完了するのを待っている間にIRP（IO要求パケット）がタイムアウトしたため、再試行されたことを意味します。スレッドが開始したときIO操作、IOマネージャは、操作がシステムを通過するときに操作を表すIRPを作成します。
IRPはバッファ/ルックアサイドリストに初期状態で保存されるため、初めて失敗した場合に再試行できます。これにより、トランザクションシステムに期待される原子性が提供されるため、破損したデータや不完全なデータが大量にディスクに書き込まれることはないという確信が持てます。
このイベントは、MPIOに障害が発生した場合に最適です。 WindowsがSANストレージから何かを読み書きすることになります。リクエストがディスパッチされ、同時にSANへのケーブルの1つを切断しました。そのリクエストは決して完了しません。 Windowsは要求を再試行しますが、今回のみ、要求は他のパスをたどります。
これらのイベントは、ディスクに負荷がかかりすぎている場合、または本当に遅い場合にも発生します。これらのメッセージは、スケジュールされたバックアップなどと一致する場合があります。ディスクが低速でビジーであり、ランダムなIRPがタイムアウトし、再試行する必要があった可能性があります。 IRPは、割り込みサービスルーチン、延期されたプロシージャコールなどでスタックする可能性があります。
スタックに多くのIOフィルタードライバーがあることも、この問題を悪化させていることがわかりました。
この動作が以前のバージョンのWindowsでこのように発生したのではなく、MicrosoftがこれらのイベントをWin8/Server 2012で表示することを明らかにしただけです。
編集：カーネルデバッガーkd> !irp 1a2b3c4dを使用して、スレッドの未解決のIRPを見つけることができます。 kd> !process 8f7d6c4aは、そのプロセスに関連付けられているスレッドに関連付けられているすべてのIRPを一覧表示します。 kd> !process 0 0実行中のすべてのプロセスをリストします。
！irpコマンドを使用してIRPに関する情報を一覧表示すると、一覧で>がポイントしているため、IRPを最後に処理したドライバーを簡単に見つけることができます。次に、そのドライバーがそのIRPで実行していたことに関する詳細情報を取得するには、kd> !devobj 1a2b3c4d5e6fを実行します。これは、デバイスオブジェクトの実際のアドレスです。
次に、取得したPrivateFdoData構造のアドレスを使用してkd> dt 0x1a2b3c3c2b1a _CLASS_PRIVATE_FDO_DATAを実行します。
これで、PrivateFdoDataから取得したAllTransferPacketsListデータ構造をダンプする準備ができました。
アイデアは、IRPが最後に表示されたときに、どのドライバーがIRPで何をしていたかを追跡しているということです。 IRPが長時間AWOLである場合、タイムアウトになり、最初から再試行されます。これは、非常に多くのことが原因で発生する可能性があります。しかし重要なことは、トランザクションは最初から再試行され、IOマネージャがそうだと言うまでは完了したとは見なされません。
ああ、そしてスレッドにとらわれないIOこれは完全にワームの缶です:)
このトピックの詳細については、Mark Russinovich、MargosisなどのWindows Internals 6th Editionの第8章、I/Oシステムを推奨します。 。
**編集：**私は最終的にこのエラーの公式KBを見つけました： http://support.Microsoft.com/kb/2819485/EN-US
IO操作は、Windowsが中止するまで、1分に1回、8回再試行する必要があります。
編集：約束どおり： http://blogs.msdn.com/b/ntdebugging/archive/2013/04/30/interpreting-event-153-errors.aspx
いいえ、別のメッセージが表示され、（うまくいけば）アプリケーション層の1つがデータを正常に保存できなかった場合に例外がスローされます。
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
マイクロソフトは、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サーバーをオフに戻すのを忘れたクライアントがありました（ディスクが削除されました）。これにより、大量の問題が発生し、このエラーが主なエラーでした。
エラーを起こさずにバックアップを停止しました。