मेरे पास मल्टीप्ल IO कॉन्फ़िगर किया गया सर्वर 2012 ब्लेड है जो MPIO पथ विफलता के दौरान चेतावनी की तरह दिखाता है:
डिस्क 7 के लिए तार्किक ब्लॉक पते 0 पर IO ऑपरेशन को वापस लिया गया था।
मुझे पता है कि चेतावनी के कारण क्या हो रहा है इसलिए मैं कारण की तलाश नहीं कर रहा हूं लेकिन इस संदेश का वास्तव में क्या मतलब है?
क्या इसका मतलब यह है कि यदि यह आईओ एक लेखन ऑपरेशन था, तो सर्वर वास्तव में डेटा खो गया था जिसे वह लिखने की कोशिश कर रहा था?
इस चेतावनी संदेश के अर्थ पर किसी भी प्रकाश के लिए धन्यवाद।
जवाबों:
नहीं, इसका मतलब यह नहीं है कि डेटा खो गया था। इसका सीधा सा मतलब है कि आईआरओ (आईओ रिक्वेस्ट पैकेट) का समय समाप्त हो गया जबकि आईओ सिस्टम ने इसके पूरा होने का इंतजार किया और इसलिए इसे फिर से आजमाया गया। जब कोई थ्रेड किसी IO ऑपरेशन को शुरू करता है, तो IO प्रबंधक ऑपरेशन को दर्शाने के लिए IRP बनाता है क्योंकि यह सिस्टम से गुजरता है।
आईआरपी अपने प्रारंभिक अवस्था में बफर / लुक-साइड सूची में संग्रहीत हो जाता है, ताकि पहली बार विफल होने पर इसे वापस लिया जा सके। यह वह अमान्यता प्रदान करता है, जिसकी किसी भी व्यवहारिक प्रणाली से उम्मीद होगी ताकि हम और अधिक आत्मविश्वास से परिपूर्ण हो सकें कि आप अपनी डिस्क पर लिखे गए दूषित या अपूर्ण डेटा का एक गुच्छा नहीं लेंगे।
यह घटना MPIO विफलता की स्थिति में सही समझ में आता है। मान लें कि Windows SAN स्टोरेज से कुछ पढ़ने या लिखने के लिए जाता है। अनुरोध भेजा गया है, और उसी पल में, मैंने केबल में से एक को काट दिया SAN को। वह अनुरोध कभी पूरा नहीं होने वाला है, और इसलिए Windows अनुरोध को फिर से कोशिश करेगा, केवल इस बार अनुरोध दूसरे पथ का अनुसरण करेगा।
ये घटनाएँ तब भी होती हैं जब डिस्क ओवरबर्ड हो जाती हैं या बस वास्तव में धीमी होती हैं। आप इन संदेशों को निर्धारित बैकअप के साथ मेल खाते हुए देख सकते हैं, आदि डिस्क बस धीमी और व्यस्त हो सकती है, और कुछ यादृच्छिक आईआरपी समय पर बाहर हो गए हैं और फिर से कोशिश करनी है। आईआरपी एक बाधा सेवा दिनचर्या, या एक आस्थगित प्रक्रिया कॉल, या जो भी हो, में फंस सकता है।
मैं आपके ढेर में बहुत सारे IO फ़िल्टर ड्राइवरों को देख सकता था और साथ ही साथ इस मुद्दे को बढ़ा भी सकता था।
ऐसा नहीं है कि यह व्यवहार विंडोज के पिछले संस्करणों में ऐसा नहीं हुआ था, यह सिर्फ इतना है कि Microsoft ने स्पष्ट रूप से इन घटनाओं को Win8 या सर्वर 2012 में सतह पर लाने का फैसला किया था।
संपादित करें: आप कर्नेल डिबगर के साथ एक थ्रेड के बकाया आईआरपी पा सकते हैं: kd> !irp 1a2b3c4dजहां आपने पहले उस आदेश को जारी करके उस पते को पाया था kd> !process 8f7d6c4aजो उस प्रक्रिया से जुड़े थ्रेड से जुड़े सभी आईआरपी को सूचीबद्ध करेगा। kd> !process 0 0सभी प्रक्रियाओं को सूचीबद्ध करने के लिए।
एक बार जब आप आईआरपी कमांड का उपयोग करके आईआरपी के बारे में जानकारी सूचीबद्ध करते हैं, तो आप आसानी से यह देख सकते हैं कि किस चालक ने आईआरपी को अंतिम रूप से संभाला है क्योंकि यह >सूची में इसे इंगित करेगा । फिर उस IRP के साथ वह ड्राइवर क्या कर रहा था, इसके बारे में अधिक जानकारी प्राप्त करने के लिए, kd> !devobj 1a2b3c4d5e6fवह डिवाइस ऑब्जेक्ट का वास्तविक पता कहां है।
फिर kd> dt 0x1a2b3c3c2b1a _CLASS_PRIVATE_FDO_DATAआपके द्वारा प्राप्त PrivateFdoData संरचना के पते का उपयोग करें।
अब आप AllTransferPacketsList डेटा संरचना को PrivateFdoData से प्राप्त करने के लिए तैयार हैं।
विचार यह है कि आप नीचे ट्रैक कर रहे हैं कि ड्राइवर क्या कर रहा था, आईआरपी के साथ पिछली बार जब यह देखा गया था। यदि IRP बहुत लंबे समय के लिए AWOL है, तो यह समय से समाप्त हो गया है और शुरुआत से ही पीछे हट गया है। यह बहुत सी चीजों के कारण हो सकता है ... यहां तक कि एक आवारा लौकिक किरण भी। लेकिन महत्वपूर्ण बात यह है कि लेन-देन शुरू से ही वापस ले लिया जाएगा, और इसे तब तक पूरा नहीं माना जाएगा जब तक कि आईओ प्रबंधक यह न कहे।
ओह, और थ्रेड-अज्ञेयवादी IO भी है जो कि कीड़े की एक पूरी तरह से अलग किस्म है। :)
इस विषय पर आगे पढ़ने के लिए, मैं मार्क रोसिनोविच, मार्गोसिस, एट अल से विंडोज इंटर्नल 6 वें संस्करण के अध्याय 8, I / O सिस्टम की अत्यधिक अनुशंसा करता हूं।
** संपादित करें: ** मुझे आखिरकार इस त्रुटि के लिए आधिकारिक KB मिला: http://support.microsoft.com/kb/2819485/EN-US
आईओ ऑपरेशन को प्रति मिनट 8 बार, जब तक कि विंडोज नहीं देता, तब तक पीछे हट जाना चाहिए।
संपादित करें: जैसा कि वादा किया गया है: 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 संचालन के लिए सीमा निर्दिष्ट करने की क्षमता प्रदान करता है।
इस अद्यतन को स्थापित करने के बाद, आप किसी इवेंट को लॉग इन कर सकते हैं जब I / O से स्टोरेज के लिए विलंबता का समय थ्रेशोल्ड के बराबर या उससे अधिक है। सीमा मूल्य उपयोगकर्ता द्वारा निर्धारित किया जा सकता है। यह ऑपरेशन एडेप्टर ड्राइवर स्तर पर किया जाता है ताकि आप देख सकें कि सैन पर कोई प्रदर्शन समस्या है या नहीं। फिर, आप समस्या को हल करने के लिए किसी स्टोरेज वेंडर से संपर्क कर सकते हैं।
नोट: यह अद्यतन Windows 7 और Windows Server 2008 R2 में दी गई कार्यक्षमता को पुनर्स्थापित करता है। जब कार्यक्षमता सक्षम होती है, तो थ्रेशोल्ड मान 100 नैनोसेकंड (0.0001 मिलीसेकंड) में मापा जाता है। साथ ही, ईवेंट में निम्न मान लॉग किए गए हैं:
BuildIoDuration : समय जो मिनिपोर्ट इस अनुरोध के लिए निर्माण आई / ओ समारोह में बिताया है की लंबाई StartIoDuration समय अवधि जो मिनिपोर्ट मैं शुरू / इस अनुरोध के लिए हे समारोह में खर्च किया गया है: DataTransferLength बाइट में हस्तांतरण का आकार:
अद्यतन जो Windows Server 2012 में Storport.sys ड्राइवर की लॉगिंग क्षमताओं को बेहतर बनाता है
http://support.microsoft.com/kb/2819476
विंडोज 8 और विंडोज सर्वर 2012 संचयी अद्यतन: अप्रैल 2013
http://support.microsoft.com/kb/2822241
एक देर से पोस्ट हो सकता है, लेकिन मैंने पाया है कि यह वीएसएस के साथ हो सकता है। हमारे पास एक मुवक्किल था जो वीलम चला रहा था लेकिन विंडोज़ सर्वर को बंद करना भूल गया था (डिस्क को हटा दिया गया था) इससे समस्याओं का एक शेड लोड हो गया और यह त्रुटि मुख्य थी।
स्टॉप बैक अप एंड वम, नो एरर।