У мене встановлено багатошаровий IO-сервер, лезо 2012, яке показує такі попередження під час відмови MPIO шляху:
Операція вводу-виводу за адресою логічного блоку 0 для диска 7 була повторена.
Я знаю, що викликає попередження, тому я не шукаю причини, але що це означає насправді?
Чи означає це, що якщо цей IO був операцією з запису, то сервер фактично втратив дані, які він намагався записати?
Дякуємо за будь-яке світло, яке ви можете пролити на значення цього попереджувального повідомлення.
Відповіді:
Ні це не означає, що дані були втрачені. Це просто означає, що IRP (IO Request Packet) вичерпався, поки система IO чекала його завершення, і тому його спробували ще раз. Коли потік починає будь-яку операцію вводу-виводу, менеджер IO створює IRP для представлення операції під час проходження через систему.
IRP зберігається у своєму початковому стані у списку буфера / дивитися, так що його можна буде повторити, якщо він не працює вперше. Це забезпечує атомність, яку можна було б очікувати від будь-якої транзакційної системи, щоб ми могли бути впевненішими, що ви не збираєтесь отримати купу пошкоджених або неповних даних, записаних на ваш диск.
Ця подія має ідеальний сенс у випадку відмови MPIO. Скажімо, Windows іде читати чи записувати щось із сховища SAN. Запит відправляється, і в цю ж мить я перерізав один з кабелів до SAN. Цей запит ніколи не завершиться, і тому Windows повторно спробує запит, лише цього разу запит піде іншим шляхом.
Ці події також трапляються, коли диски перевантажені або просто дуже повільні. Ви можете помітити, що ці повідомлення збігаються із запланованими резервними копіями і т. Д. Диск може бути повільним і зайнятим, а деякі випадкові IRP вимкнулися і довелося спробувати ще раз. IRP може застрягнути в процедурі переривання обслуговування, або відкладеному дзвінку процедури, або будь-якому іншому.
Я міг помітити, що у вашому стеці багато драйверів фільтру вводу-виводу, що також загострює цю проблему.
Справа не в тому, що така поведінка не відбулася так, як це було в попередніх версіях Windows, це лише те, що Microsoft, мабуть, вирішила перекрити ці події в 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, яку ви отримали.
Тепер ви готові скинути структуру даних AllTransferPacketsList, отриману від PrivateFdoData.
Ідея полягає в тому, що ви відстежуєте, що драйвер робив, що робив з IRP востаннє, коли його бачили. Якщо IRP занадто довго AWOL, він вимикається та повторюється з початку. Це може бути викликано багатьма речами ... навіть бродячим космічним променем. Але важливим є те, що транзакція буде повторно повторена, і вона не вважатиметься завершеною, доки менеджер IO не скаже, що вона є.
Ой, а також є ниткоагностичний введення-вивід, який є зовсім іншим банком глистів. :)
Для подальшого читання з цієї теми я настійно рекомендую главу 8, Система вводу / виводу 6-го видання Windows Internals, від Марка Русиновича, Margosis та ін.
** Редагувати: ** Я нарешті знайшов офіційний КБ для цієї помилки: http://support.microsoft.com/kb/2819485/EN-US
Операцію вводу-виводу слід повторити 8 разів, раз на хвилину, поки Windows не здасться.
Редагувати: Як обіцяли: http://blogs.msdn.com/b/ntdebugging/archive/2013/04/30/interpreting-event-153-errors.aspx
Ні, не було б іншого повідомлення, і (сподіваємось), один із шарів програми видасть виняток, якщо не вдалося успішно зберегти дані.
До Windows Server 2012 (або виправлення 2819485, якщо на Windows Server 2008 R2) система мовчки повторить спробу, коли виникли ці очікування. Мета повідомлення - збільшити видимість щодо цих подій. Вони можуть вказувати на проблеми з ємністю або недоліком драйвера, а у випадку iSCSI інші дефекти операційної системи можуть бути пов’язані із затримкою.
Що стосується зовнішнього (не додається до прямого) зберігання, деякі постачальники в минулому збільшували значення тайм-ауту, наприклад, до 60 секунд. Однак, враховуючи за замовчуванням кількість повторних спроб компонентів вищого рівня, таких як ініціатор iSCSI, це може означати, що може пройти кілька хвилин до того, як система ініціювала відмову. Очевидно, це буде неоптимальна поведінка.
Більше інформації:
Записи реєстру для драйверів SCSI Miniport
http://msdn.microsoft.com/en-us/library/windows/hardware/ff563970%28v=vs.85%29.aspx
Microsoft випустила оновлення, яке надає можливість визначати поріг для операцій storport.sys.
Після встановлення цього оновлення ви можете зареєструвати подію, коли час затримки для зберігання вводу-виводу для зберігання дорівнює або перевищує поріг. Порогове значення може встановити користувач. Ця операція виконується на рівні драйвера адаптера, щоб ви могли побачити, чи є проблема з продуктивністю на SAN. Потім ви можете зв’язатися з продавцем сховища, щоб вирішити проблему.
Примітка. Це оновлення відновлює функціональні можливості, передбачені в Windows 7 та Windows Server 2008 R2. Коли функціонал включений, порогове значення вимірюється в 100 наносекунд (0,0001 мілісекунд). Крім того, у події реєструються такі значення:
BuildIoDuration : Тривалість часу, який MINIPORT витратив на функцію збірки вводу / виводу для цього запиту StartIoDuration : Тривалість часу, який MINIPORT витратив на функцію запуску вводу / виводу для цього запиту DataTransferLength : Розмір передачі в байтах
Оновлення, що покращує можливості реєстрації драйвера Storport.sys у Windows Server 2012
http://support.microsoft.com/kb/2819476
Сукупне оновлення для Windows 8 та Windows Server 2012: квітень 2013
http://support.microsoft.com/kb/2822241
Можливо, це буде пізня посада, але я виявив, що це може бути спричинено через VSS. У нас був клієнт, який запускав veeam, але забув вимкнути резервну копію сервера Windows (диск видалено) Це спричинило навантаження проблем, і ця помилка була основною.
Припинив резервну копію і почав, помилок не було.