हार्ड ड्राइव ने त्रुटियों को पढ़ा ... रोकें?


10

मेरी कहानी काफी सरल रूप से शुरू होती है। मेरे पास एक लाइट-ड्यूटी सर्वर है, जो आर्क लिनक्स चला रहा है, जो अपने डेटा का अधिकांश भाग RAID -1 पर दो SATA ड्राइव से बना है। यह लगभग 4 महीने तक बिना किसी समस्या के काम कर रहा था। फिर, अचानक मुझे ड्राइव में से एक पर रीड एरर मिलने लगीं। हमेशा, संदेश बहुत कुछ इस तरह दिखते थे:

Apr 18 00:20:15 hope kernel: [307085.582035] ata5.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
Apr 18 00:20:15 hope kernel: [307085.582040] ata5.01: failed command: READ DMA EXT
Apr 18 00:20:15 hope kernel: [307085.582048] ata5.01: cmd 25/00:08:08:6a:34/00:00:27:00:00/f0 tag 0 dma 4096 in
Apr 18 00:20:15 hope kernel: [307085.582050]          res 51/40:00:0c:6a:34/40:00:27:00:00/f0 Emask 0x9 (media error)
Apr 18 00:20:15 hope kernel: [307085.582053] ata5.01: status: { DRDY ERR }
Apr 18 00:20:15 hope kernel: [307085.582056] ata5.01: error: { UNC }
Apr 18 00:20:15 hope kernel: [307085.621301] ata5.00: configured for UDMA/133
Apr 18 00:20:15 hope kernel: [307085.640972] ata5.01: configured for UDMA/133
Apr 18 00:20:15 hope kernel: [307085.640986] sd 4:0:1:0: [sdd] Unhandled sense code
Apr 18 00:20:15 hope kernel: [307085.640989] sd 4:0:1:0: [sdd]  Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Apr 18 00:20:15 hope kernel: [307085.640993] sd 4:0:1:0: [sdd]  Sense Key : Medium Error [current] [descriptor]
Apr 18 00:20:15 hope kernel: [307085.640998] Descriptor sense data with sense descriptors (in hex):
Apr 18 00:20:15 hope kernel: [307085.641001]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
Apr 18 00:20:15 hope kernel: [307085.641010]         27 34 6a 0c 
Apr 18 00:20:15 hope kernel: [307085.641020] sd 4:0:1:0: [sdd]  Add. Sense: Unrecovered read error - auto reallocate failed
Apr 18 00:20:15 hope kernel: [307085.641023] sd 4:0:1:0: [sdd] CDB: Read(10): 28 00 27 34 6a 08 00 00 08 00
Apr 18 00:20:15 hope kernel: [307085.641027] end_request: I/O error, dev sdd, sector 657746444
Apr 18 00:20:15 hope kernel: [307085.641035] ata5: EH complete
Apr 18 00:20:15 hope kernel: [307085.641672] md/raid1:md16: read error corrected (8 sectors at 657744392 on sdd1)
Apr 18 00:20:17 hope kernel: [307087.505082] md/raid1:md16: redirecting sector 657742336 to other mirror: sdd1

प्रत्येक त्रुटि ने एक अलग सेक्टर नंबर की शिकायत की, और डिस्क तक पहुंचने वाले उपयोगकर्ता (मेरे) के लिए कई सेकंड की देरी के साथ।

मैंने स्मार्टक्लाट आउटपुट की जाँच की, और निम्न आउटपुट (अप्रासंगिक भागों की कतरन) को देखा:

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   193   193   051    Pre-fail  Always       -       1606
  5 Reallocated_Sector_Ct   0x0033   194   194   140    Pre-fail  Always       -       0
196 Reallocated_Event_Count 0x0032   162   162   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       51

लॉग में वापस देखते हुए, मैंने पाया कि त्रुटियां वास्तव में कुछ दिनों से हो रही थीं, ज्यादातर बैकअप के दौरान, लेकिन अक्सर बहुत हल्के उपयोग के दौरान (प्रत्येक 5 वीं बार जब मैंने एक पाठ फ़ाइल को बचाने की कोशिश की)। मैंने निष्कर्ष निकाला कि मेरी डिस्क मर रही थी, कि RAID-1 इसे उचित तरीके से संभाल रहा था, और यह एक प्रतिस्थापन डिस्क का आदेश देने का समय था। मैंने एक नई डिस्क का आदेश दिया।

मेरे आश्चर्य के अधिकांश, एक दिन बाद, त्रुटियाँ ... बंद हो गईं। मैंने उन्हें ठीक करने के लिए कुछ नहीं किया था। मैंने रिबूट नहीं किया था, ऑफ़लाइन ड्राइव नहीं लिया था, कुछ भी नहीं। लेकिन त्रुटियां बस रुक गईं।

उस बिंदु पर, यह देखने के लिए उत्सुक है कि क्या खराब सेक्टर अभी डिस्क के निष्क्रिय भागों में थे, मैंने डिस्क को RAID से बाहर निकाल दिया, इसे वापस RAID में डाल दिया, और इसे पूर्ण रेसक्यू को पूरा करने की अनुमति दी। 9 घंटे बाद (2TB डिस्क थोड़ी देर लगती है) बिना किसी त्रुटि के पूरा हुआ रिस्क्यूंक।

इसके अलावा, स्मार्टक्लाट आउटपुट में थोड़ा बदलाव आया है:

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   193   193   051    Pre-fail  Always       -       1606
  5 Reallocated_Sector_Ct   0x0033   194   194   140    Pre-fail  Always       -       43
196 Reallocated_Event_Count 0x0032   162   162   000    Old_age   Always       -       38
197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       0

तो, इसका एक हिस्सा जो मुझे परेशान कर रहा है, निश्चित रूप से, "जब से खराब डिस्क खुद को ठीक करते हैं?"

मुझे लगता है कि यह संभव है कि ड्राइव का एक बहुत छोटा क्षेत्र अनायास खराब हो गया, और यह कि ड्राइव को अपने सेक्टर रिक्लेक्शन कोड को किक करने में 3 दिन (!) लगे और इससे डिस्क के खराब क्षेत्र में कुछ अतिरिक्त सेक्टर मैप हो गए ... लेकिन मैं यह नहीं कह सकता कि मैंने कभी ऐसा देखा है।

क्या किसी और ने भी इस तरह का व्यवहार देखा है? यदि हां, तो बाद में ड्राइव के साथ आपका अनुभव क्या था? क्या यह फिर से हुआ? क्या डिस्क अंततः पूरी तरह से विफल हो गई? या यह सिर्फ एक अस्पष्टीकृत गड़बड़ थी जो अस्पष्टीकृत बनी रही?

मेरे मामले में, मेरे पास पहले से ही प्रतिस्थापन ड्राइव (वारंटी के तहत प्राप्त) है, इसलिए मैं शायद वैसे भी ड्राइव को बदल दूंगा। लेकिन मुझे यह जानकर अच्छा लगेगा कि अगर मैंने इसे किसी तरह गलत बताया। यदि यह मदद करता है, तो मेरे पास 'smartctl -a' आउटपुट है जब समस्या हो रही थी। यह अभी थोड़ा लंबा है, इसलिए मैंने इसे यहां पोस्ट नहीं किया।


ड्राइव का मेक एंड मॉडल क्या है?
एंटोनियस बलोच

यह एक वेस्टर्न डिजिटल कैवियार ब्लैक 2TB ड्राइव है, मॉडल WD2001FAAS। मुझे पता है, बिल्कुल सर्वर-ग्रेड डिस्क नहीं, लेकिन यह डेटा सेंटर उत्पादन-ग्रेड सर्वर भी नहीं है।
रिक कोशी

जवाबों:


9

यदि ड्राइव सतह का एक विशिष्ट भौतिक क्षेत्र खराब हो जाता है, तो जब तक उन क्षेत्रों को सफलतापूर्वक मैप नहीं किया जा सकता, तब तक आपको उस क्षेत्र में लिखे गए किसी भी डेटा को पढ़ने की कोशिश करने पर अप्राप्य पढ़ने में त्रुटियां मिलेंगी। ड्राइव को पता है कि सेक्टर खराब हैं (सेक्टरों को एक्सेस करने में विफलताओं के बाद), लेकिन सेक्टरों को रीमैप नहीं कर सकते क्योंकि वे पहले से ही डेटा रखते हैं। यदि आप ड्राइव को प्रारूपित करते हैं या "खराब" क्षेत्रों को अधिलेखित करते हैं, तो ड्राइव के पास बुरे क्षेत्रों को मैप करने का अवसर होगा।

एक बार खराब सेक्टर्स को मैप कर दिया जाता है, और जब तक ड्राइव सरफेस का अधिक हिस्सा फेल नहीं हो जाता, आप अच्छे शेप में आ जाते हैं।

मुझे पता नहीं है कि वर्तमान ड्राइव के ड्राइव विफलता मॉडल के बारे में पर्याप्त पता है कि क्या मीडिया की सतह के एक हिस्से के बीच बहुत सहसंबंध है जो खराब हो रहा है और समस्या फिर से फैल रही है या हो रही है। यदि कोई सहसंबंध नहीं है, तो एक बार बुरे क्षेत्रों को बाहर निकालने के बाद, आप अच्छे आकार में हैं। अगर वहाँ है एक संबंध है, तो इस ड्राइव के अंत की शुरुआत है।


4

अधिकांश आधुनिक ड्राइव एक ब्लॉक को "वेक्टर आउट" करेंगे जो खराब हो गया है। ड्राइव में अतिरिक्त ब्लॉकों का एक पूल होता है और फर्मवेयर किसी भी ब्लॉक को बदलने के लिए इनका उपयोग करता है जो ड्राइव के खराब होने के लिए जाने जाते हैं। जब यह किसी ब्लॉक को सही डेटा की आपूर्ति नहीं कर सकता, तो ड्राइव इस री-मैपिंग को नहीं कर सकता। यह सिर्फ "रीड एरर" देता है। यह ब्लॉक को खराब के रूप में चिह्नित करता है, इसलिए यदि ब्लॉक कभी सही ढंग से पढ़ता है तो ब्लॉक को बाहर निकाल दिया जाता है और सही डेटा को ब्लॉक को लिखा जाता है। यदि OS कभी एक ऐसे ब्लॉक में पहुंच जाता है जो "वेक्टर आउट लंबित" स्थिति में है, तो ब्लॉक को हटा दिया जाता है और डेटा को प्रतिस्थापन ब्लॉक को लिखा जाता है।

किसी उपकरण से रीड एरर प्राप्त करने पर, लिनक्स सॉफ्टवेयर छापे, सरणी में अन्य तत्वों से सही डेटा प्राप्त करते हैं और फिर यह खराब ब्लॉक को फिर से लिखने की कोशिश करता है। एसओ, अगर राइट ठीक काम करता है, तो डेटा सुरक्षित है, यदि नहीं, तो ड्राइव सिर्फ ऊपर करता है, ब्लॉक को वैक्टर करता है और फिर राइट को परफॉर्म करता है। एसओ, ड्राइव ने छापे प्रणाली की मदद से, बस खुद की मरम्मत की है!

इस तरह की घटनाओं को यथोचित रूप से दुर्लभ मानकर, संभवतः इसे जारी रखना सुरक्षित है। यदि बहुत अधिक प्रतिस्थापन ब्लॉक का उपयोग किया जा रहा है, तो ड्राइव में समस्या हो सकती है। इस बात की एक सीमा है कि कितने प्रतिस्थापन ब्लॉकों को स्पेयर ब्लॉक में बदला जा सकता है और यह ड्राइव का एक कार्य है।


3

हां, मैंने इसे भी देखा है, और इसी तरह की परिस्थितियों में भी। मेरे मामले में, यह एक "उपभोक्ता-ग्रेड" पश्चिमी डिजिटल 1TB "ग्रीन" ड्राइव (WD10EARS) था जिसने मुझ पर उस स्टंट को खींचा। स्मार्ट Current_Pending_Sectorकच्चे मूल्य शून्य से 6 तक चला गया, और फिर 8 तक, स्मार्ट मॉनिटरिंग डेमॉन ने मुझे कुछ अशुभ ईमेल भेजने के लिए प्रेरित किया।

मैं सरणी से ड्राइव को mdadm --failएड और --removeडी करता हूं और badblocksइसके ऊपर एक गैर-विनाशकारी पास चलाता है , और हां, जाहिरा तौर पर 2 दर्जन से अधिक बुरे ब्लॉक थे। जब प्रतिस्थापन ड्राइव एक दिन बाद आया, तो मैंने सरणी को ठीक कर दिया, और जीवन आगे बढ़ गया।

इसके तुरंत बाद, सरासर ऊब से बाहर, मैं badblocks"विफल" ड्राइव पर फिर से देखने के लिए कि क्या यह खराब हो गया था। इसके विपरीत, ड्राइव ने खुद को पूरी तरह से "मरम्मत" किया था: शून्य खराब ब्लॉक! मेरे सिर को हिलाते हुए, मैंने इसे मिटा दिया और इसे पुनर्नवीनीकरण या दान करने के लिए अलग रखा।

सबक: सर्वर-ग्रेड ड्राइव का उपयोग सर्वर में न करें, जब तक कि आप सभी तरह के अजीब और अविश्वसनीयता के साथ तैयार न हों। कोरोलरी: सर्वर घटकों पर सस्ता-आउट न करें, क्योंकि आप अंततः उनके लिए अतिरिक्त समय और वृद्धि में भुगतान करेंगे।


यदि खराब ब्लॉक पाए गए तो सभी सफलतापूर्वक मैप किए गए, और कोई भी अतिरिक्त सेक्टर खराब नहीं हुआ, तो आपके परिणाम वही हैं जो आप देखने की उम्मीद करते हैं। आपका अंतिम पैराग्राफ हालांकि अभी भी सही उत्तर है।
एडी

0

सर्वर वातावरण में ड्राइव को खत्म करने के लिए यह आम बात है कि इस तरह की त्रुटियों को कभी भी तय या नहीं दिखाया गया है। सेक्टर की हार्ड एरर मीडियम में भौतिक सरफेस डैमेज का संकेत हो सकता है - और अगर आप किसी सतह को स्क्रैच करते हैं, तो आप आमतौर पर या तो स्क्रैच के किनारों पर सामग्री को विस्थापित कर देते हैं और ऐसी सतह के प्लेन की तुलना में अधिक ऊंचा हो जाता है - या अपघर्षक डस्ट (कांच! )। दोनों एक यांत्रिक प्रणाली के लिए हानिकारक होते हैं, जो दो सतहों के बीच बहुत पतली हवा के कुशन पर निर्भर होता है, पूरी तरह से चिकनी होती है ... यही कारण है कि एक बार एक निश्चित गणना तक पहुंचने के लिए मध्यम त्रुटियों के बजाय अधिक तेज़ी से गुणा करना शुरू हो जाता है।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.