Tidak, itu tidak berarti bahwa data itu hilang. Ini hanya berarti bahwa IRP (Paket Permintaan IO) habis sementara Sistem IO menunggu untuk selesai, dan karenanya dicoba lagi. Ketika utas memulai operasi IO, manajer IO membuat IRP untuk mewakili operasi saat melewati sistem.
IRP disimpan dalam keadaan awal dalam daftar buffer / look-selain, sehingga dapat dicoba lagi jika gagal pertama kali. Itu memberikan atomicity yang diharapkan dari sistem transaksional apa pun sehingga kami dapat lebih yakin bahwa Anda tidak akan mendapatkan banyak data yang rusak atau tidak lengkap yang ditulis ke disk Anda.
Acara ini sangat masuk akal jika terjadi kegagalan MPIO. Katakanlah Windows masuk untuk membaca atau menulis sesuatu dari penyimpanan SAN. Permintaan dikirim, dan pada saat yang sama, saya memotong salah satu kabel ke SAN. Permintaan itu tidak akan pernah selesai, dan karenanya Windows akan mencoba permintaan itu lagi, hanya saja kali ini permintaan akan mengikuti jalur lainnya.
Peristiwa ini juga terjadi ketika disk overburdened atau hanya sangat lambat. Anda mungkin melihat pesan-pesan ini bertepatan dengan cadangan terjadwal, dll. Disk mungkin lambat dan sibuk, dan beberapa IRP acak habis dan harus mencoba lagi. IRP bisa saja terjebak dalam rutinitas layanan interupsi, atau panggilan prosedur yang ditangguhkan, atau apa pun.
Saya bisa melihat memiliki banyak pengandar filter IO di tumpukan Anda memperburuk masalah ini juga.
Bukan karena perilaku ini tidak terjadi seperti ini di versi Windows sebelumnya, hanya saja Microsoft tampaknya memutuskan untuk memunculkan peristiwa ini di Win8 / Server 2012.
Sunting: Anda dapat menemukan IRP yang luar biasa dari utas dengan debugger kernel:, kd> !irp 1a2b3c4dtempat Anda sebelumnya menemukan alamat itu dengan mengeluarkan perintah kd> !process 8f7d6c4ayang akan mencantumkan semua IRP yang terkait dengan utas yang terkait dengan proses itu. kd> !process 0 0untuk membuat daftar semua proses yang berjalan.
Setelah Anda mencantumkan informasi tentang IRP menggunakan perintah! Irp, Anda dapat dengan mudah menemukan driver mana yang terakhir menangani IRP karena itu akan >menunjuk ke dalamnya dalam daftar. Kemudian untuk mendapatkan informasi lebih lanjut tentang apa yang driver lakukan dengan IRP itu, lakukan di kd> !devobj 1a2b3c4d5e6fmana itu adalah alamat sebenarnya dari objek perangkat.
Kemudian lakukan kd> dt 0x1a2b3c3c2b1a _CLASS_PRIVATE_FDO_DATAmenggunakan alamat struktur PrivateFdoData yang Anda dapatkan.
Sekarang Anda siap untuk membuang struktur data AllTransferPacketsList yang Anda dapatkan dari PrivateFdoData.
Idenya adalah, Anda melacak driver apa yang melakukan apa dengan IRP terakhir kali terlihat. Jika IRP terlalu lama, itu habis dan coba lagi dari awal. Ini bisa disebabkan oleh begitu banyak hal ... bahkan sinar kosmik yang tersesat. Tetapi yang penting adalah bahwa transaksi akan dicoba kembali dari awal, dan itu tidak akan dianggap lengkap sampai manajer IO mengatakan itu.
Oh, dan ada juga benang-agnostik IO yang merupakan kaleng cacing yang sama sekali berbeda. :)
Untuk membaca lebih lanjut tentang topik ini, saya sangat merekomendasikan bab 8, Sistem I / O, Windows 6 edisi Internals, dari Mark Russinovich, Margosis, et al.
Edit **: ** Saya akhirnya menemukan KB resmi untuk kesalahan ini: http://support.microsoft.com/kb/2819485/EN-US
Operasi IO harus dicoba lagi 8 kali, sekali per menit, sampai Windows menyerah.
Sunting: Seperti yang dijanjikan: http://blogs.msdn.com/b/ntdebugging/archive/2013/04/30/interpreting-event-153-errors.aspx