आधुनिक डिस्क पर "बैडब्लॉक" का उपयोग करना

Question

मैं अपने HDDs की जांच करने के लिए बैडब्लॉक का उपयोग करना चाहता हूं और इसके संचालन के स्पष्टीकरण की सराहना करूंगा।

किसी -bऔर के साथ का उपयोग करने के लिए सबसे अच्छा विकल्प समझा सकते हैं -c? मैंने मैन पेज से उनकी परिभाषा को शामिल किया है, लेकिन यह सुनिश्चित नहीं है कि बड़े आकार 64 एमबी रैम और 4 जीबी सेक्टर के साथ आधुनिक डिस्क के लिए फायदेमंद होंगे।

-b block-size       Specify the size of blocks in bytes. The default is 1024. 
-c number of blocks the number of blocks which are tested at a time. The default is 64

दूसरे मैं यह जानना चाहूंगा कि क्या लेखन-मोड परीक्षण गैर-विनाशकारी रीड-राइट मोड से अधिक पूरी तरह से है?

अंत में कितने SMART सेक्टर री-एलोकेशन स्वीकार्य हैं / जिन्हें नॉन-जीरो रियलाइजेशन काउंट्स के साथ ड्राइव करना चाहिए, उन्हें तुरंत बदल दिया जाए?

Comments

दूसरे भाग के लिए: जैसे ही आप बैडब्लॉक देखना शुरू करते हैं, इसका मतलब है कि कुछ गलत हो गया है। यह संभवतः एक अच्छा संकेत है, जिसे आपको डिस्क को बदलने से पहले आपको इसे बिल्कुल नहीं पढ़ना चाहिए। लेकिन सभी मामलों में, यहां तक ​​कि विफलता से पहले, आपके पास काम करने वाले कॉपी के अलावा हमेशा महत्वपूर्ण डेटा (1 स्थानीय, 1 रिमोट) के 2 बैकअप होना चाहिए। मेरे उत्तर पर विवरण देखें: superuser.com/a/528181/174998

— ओलिवियर दुलक

ब्लॉक साइज के लिए: यह वास्तविक ब्लॉक साइज को दर्शाता है जो आपका ओएस उस हार्ड ड्राइव पर डेटा स्टोर करने के लिए इस्तेमाल कर रहा था (फाइल सिस्टम के अनुसार)। यह चीजों को गति देने के लिए नहीं है, यह इतना है कि यह एक ब्लॉक "खराब" को चिह्नित करता है, यह ब्लॉक वास्तव में 1 ब्लॉक है, और 1/2 या 1 / 4th या यहां तक ​​कि 2 (या अधिक) ब्लॉक नहीं है।

— ओलिवियर दुलक

Answer 1

प्रश्न 1:

-bविकल्प के संबंध में : यह आपकी डिस्क पर निर्भर करता है। आधुनिक, बड़े डिस्क में 4KB ब्लॉक हैं, जिस स्थिति में आपको सेट करना चाहिए -b 4096। आप ऑपरेटिंग सिस्टम से ब्लॉक का आकार प्राप्त कर सकते हैं , और यह आमतौर पर या तो लेबल से डिस्क की जानकारी को पढ़कर, या डिस्क के मॉडल नंबर को गुगली करके प्राप्त करने योग्य होता है। यदि -bआपके ब्लॉक आकार से कुछ बड़ा करने के लिए सेट किया गया है, तो badblocksपरिणामों की अखंडता से समझौता किया जा सकता है (यानी आप झूठे-नकारात्मक प्राप्त कर सकते हैं: कोई बुरा ब्लॉक नहीं मिला जब वे अभी भी मौजूद हों)। यदि -bआपके ड्राइव के ब्लॉक आकार से कुछ छोटा है, तो badblocksरन की गति से समझौता किया जा सकता है। मुझे यकीन नहीं है, लेकिन सेटिंग के साथ अन्य समस्याएं भी हो सकती हैं-bआपके ब्लॉक आकार की तुलना में कुछ छोटा है, क्योंकि यह एक पूरे ब्लॉक की अखंडता की पुष्टि नहीं कर रहा है, यह अभी भी गलत-नकारात्मक प्राप्त करना संभव हो सकता है यदि यह बहुत छोटा है।

यह -cविकल्प एक साथ कितने ब्लॉक की जाँच करता है, इसके अनुरूप है। बैच पढ़ना / लिखना, मूल रूप से। यह विकल्प आपके परिणामों की अखंडता को प्रभावित नहीं करता है, लेकिन यह उस गति को प्रभावित करता है जिस पर badblocksचलता है। badblocks(वैकल्पिक रूप से) लिखेंगे, फिर पढ़ेंगे, बफर, चेक, प्रत्येक एन ब्लॉक के लिए दोहराएंगे जैसा कि निर्दिष्ट किया गया है -c। यदि -cबहुत कम सेट किया जाता है, तो यह आपके badblocksरनों को सामान्य से बहुत अधिक समय लेगा, क्योंकि कतारबद्ध और अलग आईओ अनुरोध ओवरहेड को संसाधित और संसाधित करता है, और डिस्क अतिरिक्त ओवरहेड प्रति-अनुरोध भी लगा सकता है। यदि -cबहुत अधिक सेट किया गया है, तो badblocksस्मृति समाप्त हो सकती है। यदि ऐसा होता है, badblocksतो यह शुरू होने के बाद काफी जल्दी विफल हो जाएगा। यहाँ अतिरिक्त विचारों में समानांतर badblocksरन शामिल हैं : यदि आप दौड़ रहे हैंbadblocksएक ही डिस्क (खराब विचार) पर एक से अधिक विभाजनों के खिलाफ, या एक ही IO चैनल पर कई डिस्क के खिलाफ, आप संभवतः -cकुछ उच्च समझ के साथ ट्यून करना चाहेंगे badblocksताकि स्मृति उपलब्ध हो सके ताकि समानांतर रन IO बैंडविड्थ के लिए न लड़ें और एक समझदार तरीके से समानांतर कर सकते हैं।

प्रश्न 2:

अन्य उत्तर जो इंगित करते हैं, उसके-w विपरीत, राइट-मोड टेस्ट गैर-विनाशकारी रीड-राइट टेस्ट से अधिक या कम विश्वसनीय नहीं है, लेकिन यह आपके डेटा के सभी के लिए विनाशकारी होने की कीमत पर दोगुना है। मैं समझाता हूँ क्यों:

गैर-विनाशकारी मोड में, badblocksनिम्न कार्य करता है:

1. मौजूदा डेटा पढ़ें, इसे चेकसम करें (यदि आवश्यक हो तो फिर से पढ़ें), और इसे मेमोरी में स्टोर करें।
2. -pब्लॉक के लिए एक पूर्व निर्धारित पैटर्न ( विकल्प के साथ अति-योग्य , हालांकि आमतौर पर आवश्यक नहीं है) लिखें ।
3. ब्लॉक बैक पढ़ें, यह पुष्टि करते हुए कि रीड डेटा पैटर्न के समान है।
4. मूल डेटा को डिस्क पर वापस लिखें।
   • मुझे इस पर यकीन नहीं है, लेकिन यह शायद फिर से पढ़ता है और पुष्टि करता है कि मूल डेटा सफलतापूर्वक लिखा गया था और अभी भी एक ही चीज़ के लिए चेकसम है।

विनाशकारी ( -w) मोड में, badblocksकेवल ऊपर 2 और 3 चरण करता है। इसका अर्थ है कि डेटा अखंडता को सत्यापित करने के लिए आवश्यक रीड / राइट ऑपरेशन की संख्या आधे में कट जाती है। यदि एक ब्लॉक खराब है, तो डेटा किसी भी मोड में गलत होगा। बेशक, यदि आप अपने ड्राइव पर संग्रहीत डेटा के बारे में परवाह करते हैं, तो आपको गैर-विनाशकारी मोड का उपयोग करना चाहिए, क्योंकि -wसभी डेटा को अलग करेगा और badblocksडिस्क पर लिखे पैटर्न को छोड़ देगा ।

कैविएट: यदि कोई ब्लॉक खराब हो रहा है, लेकिन पूरी तरह से अभी तक नहीं गया है, तो कुछ रीड / राइट सत्यापन जोड़े काम कर सकते हैं, और कुछ नहीं हो सकते हैं। इस मामले में, गैर-विनाशकारी मोड आपको एक ब्लॉक के "शील" का अधिक विश्वसनीय संकेत दे सकता है, क्योंकि यह रीड / राइट सत्यापन के दो सेट करता है (शायद - चरण 4 के तहत बुलेट देखें)। यहां तक ​​कि अगर गैर-विनाशकारी मोड उस तरह से अधिक विश्वसनीय है, तो यह केवल संयोग से अधिक विश्वसनीय है । ब्लॉक के लिए जाँच करने का सही तरीका जो पूरी तरह से खराब नहीं है, लेकिन विकल्प badblocksका उपयोग करते हुए एक ही डेटा पर कई बार पढ़ने / लिखने के संचालन को बनाए नहीं रख -pसकता है।

प्रश्न 3:

यदि SMART सेक्टरों को अलग कर रहा है, तो आपको संभवतः ASAP ड्राइव को बदलने पर विचार करना चाहिए। ड्राइव जो कुछ क्षेत्रों को खो देते हैं, उन्हें हमेशा खोते नहीं रहते हैं, लेकिन इसका कारण आमतौर पर एक अत्यधिक उपयोग किया जाने वाला ड्राइव है जो चुंबकीय रूप से विक्षिप्त हो रहा है, या गलत तरीके से चलने वाले हेड / मोटर्स के परिणामस्वरूप गलत या विफल रीड / लिखते हैं। अंतिम निर्णय आप पर निर्भर करता है, निश्चित रूप से: ड्राइव पर डेटा के मूल्य और उस पर आपके द्वारा चलाए जाने वाले सिस्टम से आपकी विश्वसनीयता की आवश्यकता के आधार पर, आप इसे बनाए रखने का निर्णय ले सकते हैं। मेरे पास कुछ बुरे ब्लॉकों के साथ कुछ ड्राइव हैं जो मेरे फाइलरवर में सालों से SMART चेतावनियों के साथ घूम रहे हैं, लेकिन वे एक शेड्यूल पर बैकअप ले रहे हैं ताकि मैं बिना किसी दर्द के कुल विफलता को संभाल सकूं।

Comments

किसी भी विचार क्यों -bचूक करने के लिए 1024? यह मुझे अजीब लगता है। क्यों नहीं 512?

— रयान जे

@RRJJ 1024 के लिए न्यूनतम ब्लॉक आकार है ext2। badblocks e2fsprogs का हिस्सा है, और मूल रूप से एक ext2 फाइलसिस्टम के खराब ब्लॉकों की सूची को आबाद करने का इरादा था। आपको mkfs.ext2 के लिए सही प्रारूप में नंबर प्राप्त करने के लिए FS के समान अवरोधक के साथ इसे चलाना होगा। टीएल; डीआर: ऐतिहासिक कारण जो आपको चिंतित नहीं होना चाहिए।

— sourcejedi

BUUUTT, @Zac B ने कहा "अगर -b आपके ब्लॉक आकार से कुछ बड़ा है, तो बैडब्लॉक परिणामों की अखंडता से समझौता किया जा सकता है" 1024> 512. मैं समझ सकता हूं कि कैसे 513 अनियंत्रित होने के लिए कुछ बाइटस्ट का कारण बन सकता है। लेकिन शायद इसे बहाल किया जाना चाहिए "यदि -बी आपके ब्लॉक आकार से कुछ बड़ा हो गया है और न ही ईवेंट मल्टीप्लेयर नहीं है, तो बैडब्लॉक परिणामों की अखंडता से समझौता किया जा सकता है"। आप क्या कहते हैं मूल पोस्टर, अन्य लोग मुझसे ज्यादा स्मार्ट हैं?

— बिली सी।

Answer 2

1) यदि आपकी आधुनिक डिस्क सेक्टर साइज़ को अन्य 512b का उपयोग करती है - तो आपको -bविकल्प (यानी -b 4096) के साथ उस आकार को सेट करना होगा । उस विकल्प के बिना आपका चेक बहुत धीमी गति से चलेगा क्योंकि प्रत्येक वास्तविक क्षेत्र में कई बार प्रयास किया जाएगा (4k क्षेत्र के मामले में 8 बार)। प्रश्न में टिप्पणी के रूप में ओलिवियर दुलैक का उल्लेखblock is indeed 1 block, and not 1/2 or 1/4th or even 2 (or more) blocks.

-cएक बार में कितने सेक्टर ट्रायड करते हैं, इस पर विकल्प । यह प्रदर्शन पर कुछ प्रभाव डाल सकता है और उस प्रदर्शन का मूल्य विशिष्ट डिस्क मॉडल पर निर्भर कर सकता है।

2) write-mode test- मेरी समझ में यह केवल तभी जांच करेगा कि आपके पास हार्ड-बैड एरर है या सॉफ्ट-बैड एरर (उर्फ साइलेंट डेटा डिग्रेडेशन, बिट रोट, स्टोरेज मीडिया का क्षय, UNC सेक्टर्स)

3) मैं उस समय में स्मार्ट रिपोर्ट पर भरोसा नहीं करूंगा। यह अधिक महत्वपूर्ण है कि समय के माध्यम से मूल्य कैसे बदलते हैं। यहाँ भी एक बड़ी डिस्क ड्राइव जनसंख्या में Google विफलता के रुझान का अनुसंधान किया गया है और यहाँ इसकी कुछ चर्चा है। यहाँ अनुसंधान से उद्धृत है:

इस उच्च सहसंबंध के बावजूद, हम यह निष्कर्ष निकालते हैं कि अकेले SMART मापदंडों पर आधारित मॉडल व्यक्तिगत ड्राइव विफलताओं की भविष्यवाणी करने के लिए उपयोगी होने की संभावना नहीं है।

डिस्क प्रतिस्थापन के लिए अन्य द्वारा उल्लेखों के बारे में - आपको हार्ड-खराब डिस्क समस्या नहीं है, लेकिन साइलेंट डेटा डिग्रेडेशन (बिट रोट, स्टोरेज मीडिया, यूएनसी क्षेत्रों का क्षय) हो सकता है। उस स्थिति में डिस्क को बदलने का कोई मतलब नहीं है, लेकिन इसके बजाय डिस्क पर वापस उसी डेटा को पढ़ने / लिखने के लिए उपयोगी है। आप यहां देख सकते हैं कि इसे कैसे हल किया जा सकता है।

यदि आपके पास कठिन-खराब त्रुटि है, तो आप उस तरीके से मरम्मत करने की कोशिश कर सकते हैं जो खराब क्षेत्र किसी भी विभाजन से बाहर स्थित है। मेरे लिए वह दृष्टिकोण उपयोगी था और बिना किसी समस्या के लंबे समय तक ऐसे खराब ड्राइव का उपयोग किया जाता था।

Comments

पहला वाक्य गलत है, -b1024 में चूक। यदि आपकी डिस्क 1024 के अलावा एक सेक्टर आकार का उपयोग करती है, जो ext2 फाइलसिस्टम के बाहर बहुत आम है, तो आपको यह निर्दिष्ट करना चाहिए।

— हाशिम

Answer 3

जब तक आपके पास उन्हें बदलने का कोई विशिष्ट कारण नहीं है, मैं -b और -c को डिफ़ॉल्ट के रूप में छोड़ दूंगा। यदि आपकी डिस्क में 4k ब्लॉक आकार है तो आप शायद -b को 4096 पर सेट कर सकते हैं।

मेरा सुझाव है कि आप पहले गैर-विनाशकारी आरवी परीक्षण के साथ बैडब्लॉक चलाएं। यदि यह किसी भी खराब सेक्टर को ढूंढता है, तो डिस्क टूट गई है और इसे बदल दिया जाना चाहिए। यदि यह गैर-विनाशकारी पर कोई बुरा ब्लॉक नहीं खोजता है, लेकिन आपको अभी भी बैडब्लॉक होने पर संदेह है, तो विनाशकारी आरवी परीक्षण चलाएं।

अंत में कितने SMART सेक्टर री-एलोकेशन स्वीकार्य हैं / जिन्हें नॉन-जीरो रियलाइजेशन काउंट्स के साथ ड्राइव करना चाहिए, उन्हें तुरंत बदल दिया जाए?

जैसे ही सेक्टर बदले जा रहे हैं मैं ड्राइव को बदल दूंगा।

Comments

जैसे ही सेक्टर बदले जा रहे हैं मैं ड्राइव को बदल दूंगा। आपको कैसे पता चलेगा कि सामान्य ऑपरेशन में ब्लॉक खराब हो रहे हैं? क्या आपको किसी तरह से संकेत मिलता है?

— एलेक्सिस विल्के

आपको SMART लॉग की निगरानी करनी होगी।

— урослав Рахматуллин

जब तक कि आपके पास उन्हें बदलने का कोई विशिष्ट कारण न हो । जैसे कि डिफ़ॉल्ट 1024 से अलग ब्लॉक का आकार, जो बहुत आम है?

— कार्मेकेनो

Answer 4

इस तरह के बैडब्लॉक रीड मोड (नॉन-डिस्ट्रक्टिव) और राइट मोड (डिस्ट्रक्टिव) के बीच अंतर को जाता है:

जब कोई लेखन विफल होता है, तो एक ड्राइव केवल एक बुरे क्षेत्र को पुनः व्यवस्थित करेगा। फ़ाइलों के लिए त्रुटियों को केवल "सही" प्राप्त करें जब फ़ाइल को फिर से लिखने का प्रयास किया जाता है। अन्यथा। बुरा ब्लॉक इस धारणा पर फ़ाइल का हिस्सा है कि आप कुछ पुनर्प्राप्त करने में सक्षम हो सकते हैं। विभाजन मोड के लिए त्रुटियों को पढ़ें केवल राइट मोड में खराब ब्लॉक चलाकर और विभाजन को फिर से बनाकर "सही" किया जा सकता है

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

Answer 5

रीमैप किए गए क्षेत्रों के बारे में आपके दूसरे प्रश्न का उत्तर देने के लिए, यह निर्भर करता है। मैं एक घरेलू उपयोगकर्ता के संदर्भ से बोल रहा हूं जो (कभी-कभी) इस तरह के सामान की निगरानी करता है।

• ड्राइव पर संग्रहीत डेटा कितना महत्वपूर्ण है?
• अगर ड्राइव अचानक पेट ऊपर चला जाए तो क्या खो जाता है?
• क्या डेटा कहीं और बैकअप है?
• क्या ड्राइव RAID का सदस्य है जहां ड्राइव के नुकसान का न्यूनतम प्रभाव है?
• क्या रेप्ड सेक्टरों की संख्या बढ़ रही है?

यहां दो स्थितियों का सामना करना पड़ा। मेरे पास 6 200GB ड्राइव का एक RAID5 था। बिजली की विफलता के बाद, टिमटिमाती रोशनी के परिणामस्वरूप, एक ड्राइव ने 14 रीमैप किए गए क्षेत्रों को दिखाया और कई त्रुटियों को लॉग किया। मैंने ड्राइव देखी और कोई और त्रुटि नहीं लॉग की गई और रीमैप किया गया सेक्टर काउंट स्थिर रहा। मैंने निष्कर्ष निकाला कि ड्राइव एक शक्ति क्षणिक के कारण हुई और अन्यथा विफल नहीं हुई। मैंने वर्षों तक इसका उपयोग जारी रखा। मूल RAID5 को सेवानिवृत्त कर दिया गया था, लेकिन मेरे पास उन ड्राइवों में से दो हैं जिनकी सेवा लगभग 10 साल की है। उनके पास मुट्ठी भर रीपे्ड सेक्टर हैं। मैं अपने प्राथमिक बैकअप से वृद्धिशील बैकअप डंपों को संग्रहीत करने के लिए उनमें से दो का उपयोग करता हूं। इस तरह से मुख्य बैकअप देख रहा है (ज्यादातर) रीड ऑपरेशंस और राइट्स विभिन्न उपकरणों पर जा रहे हैं। यदि इनमें से एक प्राचीन ड्राइव विफल हो जाता है, तो दूसरे को चालू रहना चाहिए। यदि दोनों असफल हो जाते हैं, मैं उन्हें कुछ और के साथ प्रतिस्थापित करता हूं और बैकअप स्क्रिप्ट को फिर से चलाता हूं। इन ड्राइवों में से एक विफल होने पर प्रभाव शून्य के पास है, इसलिए मुझे रीमैप किए गए सेक्टरों की चिंता नहीं है।

मेरे पास एक 2TB HDD था जो कि मिरर ड्राइव की एक जोड़ी में से एक था और जो रीमैप किए गए सेक्टरों में विकसित होना शुरू हुआ। पहले यह दर्जनों था, फिर सैकड़ों, फिर हजारों। यह वर्षों की अवधि थी। जोड़ी में अन्य ड्राइव स्वस्थ रहे और वास्तव में, धीरे-धीरे विफल होने वाले व्युत्पन्न को सरणी से नहीं छोड़ा गया था। आखिरकार मैंने दोनों ड्राइवों को 6TB ड्राइव्स से बदल दिया और बढ़ते हुए रीपे्ड सेक्टर की गिनती एक गैर-मुद्दा बन गई। मेरे पास अभी भी ड्राइव है और यह अभी भी "काम करता है", यहां तक ​​कि लगभग 4500 रीमैप्ड सेक्टरों के साथ भी। मैंने परीक्षण प्रणाली में इस तरह की ड्राइव लगाई है (एक RAID सदस्य के रूप में) यह देखने के लिए कि क्या होता है जब कोई वास्तव में मर जाता है। मुझे इसके साथ काम करने के लिए कुछ अवसर मिले हैं और सभी परिस्थितियों में प्रतिस्थापन बिना नाटक के चला गया।

मेरे पास मेरे प्राथमिक बैकअप फ़ाइल सर्वर पर एक ड्राइव विफल था। इसने कोई उन्नत चेतावनी नहीं दी, यह सिर्फ SATA आदेशों का जवाब देना बंद कर दिया। यह एक ZFS RAIDZ2 का सदस्य था और मैंने इसे बिना किसी नाटक के बदल दिया। वास्तव में, मेरे परीक्षण सर्वर पर मैंने बिना पावर साइकिल चलाने या सर्वर को रिबूट किए बिना विफल ड्राइव को बदल दिया है।

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