बिट सड़ांध का पता लगाने और mdadm के साथ सुधार


17

मैं अपने होम लाइन बॉक्स बॉक्स में अपने सभी HDDs को फिर से व्यवस्थित करने के बारे में हूं और डेटा सुरक्षा के लिए mdadm छापे का उपयोग करना चाहूंगा और सरणियों को फिर से व्यवस्थित करने के लिए इसके लचीलेपन का उपयोग करूंगा। हालाँकि, इससे पहले कि मैं mdadm का उपयोग करूं, मैं जानना चाहता हूं कि यह बिट रोट को कैसे संभालता है । विशेष रूप से बिट रोट के प्रकार जो HDD से भेजे जा रहे अप्राप्य रीड त्रुटि संदेशों में परिणाम नहीं करते हैं।

यह देखते हुए कि मैं HDDs के कम से कम 21TB NAS में 8 डिस्क और पर विभिन्न उद्धरण में होने की संभावना का उपयोग किया जाएगा संभावनाओं की विफलताओं HDDs पर, मैं सोच है कि के दौरान एक एक एकल डिस्क विफलता से पुनर्निर्माण मैं मुठभेड़ की संभावना काफी हूं शेष डिस्क पर कुछ प्रकार की सड़ांध। यदि यह ड्राइव में से 1 पर एक अपरिवर्तनीय रीड एरर है, तो ड्राइव वास्तव में इसे एक त्रुटि के रूप में रिपोर्ट करता है, मेरा मानना ​​है कि raid6 (यह है?) के साथ ठीक होना चाहिए। हालाँकि यदि डिस्क से पढ़ा गया डेटा खराब है, लेकिन डिस्क द्वारा ऐसा नहीं बताया गया है, तो मैं यह नहीं देख सकता कि यह कैसे raid6 के साथ भी स्वचालित रूप से ठीक किया जा सकता है। क्या यह ऐसी चीज है जिसके बारे में हमें चिंतित होना चाहिए? लेख को देखते हुए यह 2010 है और RAID5 अभी भी काम करता है, और घर और काम पर मेरे खुद के सफल अनुभव, बातें जरूरी नहीं हैं कि कयामत और उदासी हो, क्योंकि चर्चा और विपणन हमें विश्वास होगा, लेकिन मुझे बैकअप से बहाल करने से नफरत है, क्योंकि एक एचडीडी विफल रहा।

यह देखते हुए कि उपयोग पैटर्न, कुछ ही समय में लिखेंगे, और कभी-कभी पढ़ेंगे, मुझे डेटा स्क्रबिंग करने की आवश्यकता होगी । मैं आर्चलिनक्स विकि पर mdadm कमांड के डेटा को एक सरणी के रूप में स्क्रबिंग के लिए देखता हूं

echo check > /sys/block/md0/md/sync_action

फिर प्रगति की निगरानी करना

cat /proc/mdstat

यह मुझे लगता है कि यह सभी डिस्क के सभी क्षेत्रों को पढ़ेगा और जांचेगा कि डेटा समानता और इसके विपरीत से मेल खाता है। हालाँकि, मैंने देखा कि डॉक्स में यह कहने के लिए भारी जोर है कि ऐसे महत्वपूर्ण हालात हैं कि "चेक" ऑपरेशन ऑटो सही नहीं हो पाएगा, केवल पता लगाएगा और इसे ठीक करने के लिए उपयोगकर्ता पर छोड़ देगा।

क्या mdadm RAID स्तर (s) मुझे बिट रॉट से अपनी सुरक्षा को अधिकतम करने के लिए चुनना चाहिए और मुझे क्या रखरखाव और अन्य सुरक्षात्मक कदम उठाने चाहिए? और इससे मेरी रक्षा क्या नहीं होगी?

संपादित करें: मैं एक RAID बनाम ZFS या किसी अन्य तकनीक QA को शुरू करना नहीं चाह रहा हूं। मैं विशेष रूप से mdadm छापे के बारे में जानना चाहता हूं। यही कारण है कि मैं यूनिक्स और लिनक्स पर पूछ रहा हूं और सुपरयूजर पर नहीं ।

संपादित करें: इसका उत्तर है: mdadm केवल यूआरई को सही कर सकता है जो डेटा स्क्रब के दौरान डिस्क सिस्टम द्वारा रिपोर्ट किए जाते हैं और स्क्रब के दौरान साइलेंट बिट रॉट का पता लगाते हैं लेकिन इसे ठीक नहीं कर सकते हैं?


जहाँ तक डेटा सुरक्षा की बात है, तो मुख्य लाभ जो मुझे zfs में दिखाई देता है, वह है जब भी आप फ़ाइल पढ़ते हैं, तो फाइलों की डिस्क लोकेशन को स्क्रब करते हैं। यही कारण है कि वर्तमान में मेरे पास zfs के साथ सेटअप है। लेकिन मुझे अभी भी नियमित रूप से पूर्ण स्क्रब प्रदर्शन करने की आवश्यकता है। मेरे पास 3 डिस्क के साथ प्रत्येक में 2 zfs पूल हैं, और मैं एक 8 डिस्क सिस्टम में अपग्रेड करना चाहता हूं, जहां कोई भी ड्राइव विफल हो सकती है और अभी भी 1 अधिक निरर्थक ड्राइव होगा और zfs उस तरह के फेरबदल की अनुमति देने के लिए लचीला नहीं है। चूंकि मैं वैसे भी पुनर्निर्माण कर रहा हूं, मैं mdadm पर फिर से जा रहा हूं।
बेवुल्फ़नोडे 42

आप RAID5 / 6 के साथ अब तक भाग्यशाली रहे हैं। तथ्य यह है, यह 2013 है और RAID अभी भी एक लिखने के छेद से ग्रस्त है। यदि आप डेटा लिखे जाने के बाद भी शक्ति खो देते हैं, लेकिन समानता लिखे जाने से पहले आपने अपना अच्छा डेटा दूषित कर दिया है और यह संभव है कि असंगतता के साथ कि आपका सरणी भी टोस्ट हो। धन्यवाद RAID5।
बहमट

बात यह है, कि आप जो करना चाहते हैं, वह फाइल सिस्टम लेयर पर सबसे अच्छा है। अन्यथा, आपको कम-से-कम या बिना अतिरेक की स्थिति का पता लगाने और अधिमानतः सही सड़ने के लिए किसी तरह की आवश्यकता होगी, और RAID बस इसके लिए अनुकूल नहीं है। न केवल इस बात की कोई गारंटी नहीं है कि आप वैसे भी बिट रॉट के साथ समाप्त नहीं होंगे (क्या होगा अगर एक ड्राइव विफल हो जाता है और दूसरा प्लेट को गलत तरीके से पढ़ता है?), लेकिन प्लेन RAID को यह भी पता नहीं है कि महत्वपूर्ण डेटा क्या है और क्या है। बस शोर। चूंकि ZFS केवल संदर्भित डेटा को स्क्रब करता है, डिस्क के अप्रयुक्त हिस्से पर बिट रॉट एक गैर-मुद्दा बन जाता है।
एक CVn

वास्तव में, आप अचानक स्टोरेज दोषों से बचाने के लिए कई डिस्क के ऊपर (यहां तक ​​कि अतिरेक के साथ) एक बेतरतीब फ़ाइल सिस्टम बिछाने की उम्मीद नहीं कर सकते। मैं ZFS को जनता तक लाने के लिए एक पवित्र धर्मयुद्ध पर नहीं हूं (हालांकि मुझे लगता है कि यह एक महान आविष्कार है, और मूल रूप से सब कुछ के लिए लिनक्स पर इसका उपयोग करें लेकिन रूट विभाजन, जो सॉफ्टवेयर संगतता के लिए mdraid1 पर ext4 है), लेकिन मैं यह भी पहचानता हूं कि आपकी एक ऐसी समस्या है जिसे जेडएफएस ने हल करने के लिए जमीन से तैयार किया था: गारंटी का पता लगाना और यदि संभव हो तो बिना कारण के भ्रष्टाचार की मरम्मत।
बजे एक CVn

मुझे लगता है कि आपको अपनी आवश्यकताओं को संशोधित करना चाहिए। क्या आपको वास्तव में उस मामले के लिए भी बिट्रोट सुरक्षा की आवश्यकता है जब त्रुटि सुधार लागू किया जाता है? क्या आप जानते हैं कि GIVEN के अस्तित्व के लिए बिट्रोट की संभावना कितनी कम है कि इसे डिस्क के ECC द्वारा भी सही किया गया था?
गुफामान

जवाबों:


5

सच कहूं, तो मुझे आश्चर्य हुआ कि आप RAIDZ2 ZFS को अस्वीकार कर देंगे। यह आपकी आवश्यकताओं को लगभग पूरी तरह से सूट करता है, इस तथ्य को छोड़कर कि यह लिनक्स एमडी नहीं है। मैं जेडएफएस को जन-जन तक पहुंचाने के लिए एक धर्मयुद्ध पर नहीं हूं, लेकिन साधारण तथ्य यह है कि आपकी उन समस्याओं में से एक है जिन्हें सुलझाने के लिए ज़ेडएफएस को जमीन से डिज़ाइन किया गया था । RAID पर निर्भरता (किसी भी "नियमित" RAID) को त्रुटि का पता लगाने और सुधार को संभवतः कम-या-अतिरेक स्थिति में जोखिमपूर्ण प्रदान करने के लिए जोखिम भरा है। यहां तक कि स्थितियों में, जहां ZFS नहीं कर सकते में सही कर ठीक से एक डेटा त्रुटि, यह कम से कम कर सकते हैं का पता लगाने त्रुटि और, तुम्हें पता है एक समस्या है कि वहाँ जाने आप सुधारात्मक कार्रवाई करने की इजाजत दी।

आपको ZFS के साथ नियमित रूप से पूर्ण स्क्रब करने की आवश्यकता नहीं है , हालांकि यह अनुशंसित अभ्यास है। ZFS यह सत्यापित करेगा कि डिस्क से पढ़ा गया डेटा, जो डेटा पढ़ा जा रहा है, के रूप में लिखा गया था, और बेमेल के मामले में या तो (a) मूल डेटा को फिर से संगठित करने के लिए अतिरेक का उपयोग करें, या (b) I / O त्रुटि की रिपोर्ट करें आवेदन पत्र। इसके अलावा, स्क्रबिंग एक कम प्राथमिकता वाला, ऑनलाइन ऑपरेशन है, जो अधिकांश फाइल सिस्टमों में एक फ़ाइल सिस्टम चेक से काफी अलग है जो उच्च-प्राथमिकता और ऑफ़लाइन दोनों हो सकता है। यदि आप स्क्रब चला रहे हैं और स्क्रब के अलावा कोई अन्य चीज I / O करना चाहते हैं, तो स्क्रब बैक सीट को अवधि के लिए ले जाएगा। एक ZFS स्क्रब एक RAID स्क्रब और एक फाइल सिस्टम मेटाडेटा और डेटा दोनों की जगह लेता है अखंडता की जाँच, इसलिए किसी भी बिट सड़ांध का पता लगाने के लिए RAID सरणी को छानने की तुलना में बहुत अधिक पूरी तरह से है (जो आपको यह नहीं बताता है कि क्या डेटा किसी भी अर्थ में है, केवल यह कि यह RAID नियंत्रक द्वारा सही ढंग से लिखा गया है)।

ZFS अतिरेक (RAIDZ, मिररिंग, ...) का लाभ है कि अप्रयुक्त डिस्क स्थानों को स्क्रब के लिए स्थिरता के लिए जांचने की आवश्यकता नहीं है; स्क्रब के दौरान केवल वास्तविक डेटा की जाँच की जाती है, क्योंकि उपकरण आवंटन ब्लॉक श्रृंखला को चलते हैं। यह एक गैर-निरर्थक पूल के समान है। "नियमित" RAID के लिए, सभी डेटा (डिस्क पर किसी भी अप्रयुक्त स्थानों सहित) की जांच होनी चाहिए क्योंकि RAID नियंत्रक (चाहे हार्डवेयर या सॉफ़्टवेयर) को पता नहीं है कि डेटा वास्तव में क्या प्रासंगिक है।

RAIDZ2 vdevs का उपयोग करके, कोई भी दो घटक ड्राइव विफल हो सकते हैं इससे पहले कि आप किसी अन्य ड्राइव विफलता से वास्तविक डेटा हानि का खतरा हो, क्योंकि आपके पास अतिरेक के लायक दो ड्राइव हैं। यह अनिवार्य रूप से RAID6 के समान है।

ZFS में सभी डेटा, उपयोगकर्ता डेटा और मेटाडेटा, दोनों को चेकसमेड किया जाता है (यदि आप नहीं चुनते हैं, लेकिन इसके खिलाफ अनुशंसा की जाती है) को छोड़कर, और इन चेकसमों का उपयोग यह पुष्टि करने के लिए किया जाता है कि डेटा किसी भी कारण से नहीं बदला है। फिर से, यदि एक चेकसम अपेक्षित मूल्य से मेल नहीं खाता है, तो डेटा या तो पारदर्शी रूप से पुनर्निर्माण किया जाएगा या I / O त्रुटि रिपोर्ट की जाएगी। यदि I / O त्रुटि की सूचना दी जाती है, या एक स्क्रब भ्रष्टाचार वाली फ़ाइल की पहचान करता है, तो आप एक तथ्य के लिए जानते होंगे कि उस फ़ाइल का डेटा संभावित रूप से दूषित है और बैकअप से उस विशिष्ट फ़ाइल को पुनर्स्थापित कर सकता है; एक पूर्ण सरणी पुनर्स्थापना के लिए कोई ज़रूरत नहीं है।

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

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


5
अपने मूल प्रश्न में मैं zfs बनाम RAID तर्क से बचने की कोशिश कर रहा था क्योंकि उस पर बहुत सारी जानकारी है। मैं mdadm के बारे में विशेष जानकारी चाहता हूं। इसके अलावा, क्योंकि मैं यह सुनिश्चित करने के लिए कि डेटा को नियमित रूप से साफ़ किया जाता है, मुझे यह सुनिश्चित करने के लिए अक्सर पर्याप्त डेटा को पढ़ना नहीं होगा, मुझे ज़फ़ या छापे की परवाह किए बिना नियमित रूप से एक पूर्ण सरणी स्क्रब के लिए मजबूर करना होगा।
बियोवुल्फ़नोडे42

@ BeowulfNode42 व्यक्तिगत रूप से मैं असाधारण महत्वपूर्ण डेटा के लिए एप्लिकेशन लेयर चेकसम का उपयोग करने का सुझाव देता हूं (जैसे अपने महत्वपूर्ण डेटा को चेकसम का उपयोग करें)। ZFS इसे प्रति ब्लॉक कर सकता है जो मुझे लगता है कि वास्तव में एक ओवरकिल है। मुझे लगता है कि यह बताता है कि क्यों नहीं बहुत सारे फाइल सिस्टम अपने ब्लॉक की जांच करते हैं जैसे कि ZFS करता है क्योंकि IMO यह मेरे विचार में एक एप्लीकेशन लेयर समस्या है।
गुफामान

1
@ गुफावासी मैं आपके बारे में नहीं जानता; मैं वास्तव में इस तथ्य को पसंद करता हूं कि मुझे लगातार फाइलों की जांच करने की जरूरत नहीं है कि वे भ्रष्ट हैं। निश्चित रूप से, समय का बहुत बड़ा हिस्सा कोई भ्रष्टाचार नहीं है , जिस स्थिति में कोई नुकसान नहीं हुआ है (जेडएफएस के साथ, आप एक मुट्ठी भर में चेकसम एल्गोरिथ्म की अपनी पिक प्राप्त करते हैं, इसलिए आप सुरक्षा / प्रदर्शन निरंतरता के साथ अपना पसंदीदा बिंदु चुन सकते हैं), लेकिन स्वचालित फ़ाइल सिस्टम लेवल चेकसम यह गारंटी देता है कि कोई गलत भ्रष्टाचार नहीं है क्योंकि अगर वहाँ है, तो आपको इसके बारे में जेडएफएस के मामले में भ्रष्ट डेटा के बजाय I / O त्रुटि प्राप्त होने के बारे में पता चलेगा।
एक CVn

@ माइकलकॉर्जिंग नोप यह "गारंटी" नहीं देता है (केवल डिस्क-चेक के सापेक्ष अनिर्धारित त्रुटियों की संभावना को कम करता है, एक राशि द्वारा जिसे अभी तक किसी ने मात्रा निर्धारित नहीं किया है! इसलिए कोई भी वास्तव में यह नहीं जानता है कि ZFS का चेकसमिंग कितना उपयोगी है: :), प्लस! आप एक सरल "रीड" और "राइट" रैपर्स का उपयोग कर सकते हैं जो पारदर्शी रूप से आपके लिए चेकसमिंग करते हैं। किसी को इस फैंसी चीज़ को कर्नेल स्पेस में रखने की आवश्यकता नहीं है।
गुफा

3
@ caveman नहीं, zfs विषय पर नहीं है। RAID के संभावित कार्यान्वयन संभव नहीं हैं जो mdadm नहीं हैं। मैं mdadm के बारे में जानना चाहता हूं। मैंने पहले ही इस उत्तर को जितना हो सकता है उतने वोट दिए हैं और ऑफ विषय उत्तर के बारे में अधिक जानकारी भरने वाले ऑफ टॉपिक उत्तर पर आपकी टिप्पणी मूल प्रश्न के साथ मदद नहीं कर रही है।
बियोवुल्फ़न्यूड42

3

यह उत्तर मेरे द्वारा पाए गए साक्ष्य के विभिन्न बिट्स के आधार पर तर्क का उत्पाद है। मुझे पता नहीं है कि कर्नेल लिनक्स कार्यान्वयन कैसे काम करता है, क्योंकि मैं एक कर्नेल देव नहीं हूं और लगता है कि उचित मात्रा में निरर्थक गलत जानकारी है। मुझे लगता है कि कर्नेल लिनक्स समझदार विकल्प बनाता है। मेरा उत्तर तब तक लागू होना चाहिए जब तक कि मुझसे गलती न हो।

कई ड्राइव, पढ़ने की त्रुटियों का पता लगाने के लिए ECCs (त्रुटि सुधार कोड) का उपयोग करते हैं। यदि डेटा भ्रष्ट है, तो कर्नेल को ECC सपोर्टिंग ड्राइव से उस ब्लॉक के लिए URE (अपरिवर्तनीय रीड एरर) प्राप्त करना चाहिए। इन परिस्थितियों में (और नीचे एक अपवाद है), भ्रष्ट, या खाली प्रतिलिपि, अच्छे डेटा पर डेटा पागलपन की राशि होगी। इस स्थिति में कर्नेल को पता होना चाहिए कि कौन सा डेटा अच्छा है और कौन सा डेटा खराब है। यह 2010 के अनुसार है और RAID5 अभी भी काम करता है ... लेख:

इस विकल्प पर विचार करें, मुझे पता है कि कम से कम दो सरणी विक्रेताओं द्वारा उपयोग किया जाना है। जब एक RAID वॉल्यूम में एक ड्राइव एक URE की रिपोर्ट करता है, तो सरणी नियंत्रक एक गिनती बढ़ाता है और आई / ओ को समता से ब्लॉक का पुनर्निर्माण करके संतुष्ट करता है। यह तब डिस्क पर एक फिर से लिखता है जिसने यूआरई (संभावित रूप से सत्यापित) की सूचना दी थी और यदि क्षेत्र खराब है, तो माइक्रोकोड रिमैप होगा और सब ठीक हो जाएगा।

हालाँकि, अब अपवाद के लिए: यदि कोई ड्राइव ECC का समर्थन नहीं करता है, तो एक ड्राइव डेटा भ्रष्टाचार के बारे में है, या फ़र्मवेयर विशेष रूप से विघटनकारी है, तो एक URE की सूचना नहीं दी जा सकती है, और दूषित डेटा कर्नेल को दिया जाएगा। डेटा को मिसमैच करने के मामले में: ऐसा लगता है कि यदि आप 2 डिस्क RAID1, या RAID5 का उपयोग कर रहे हैं, तो कर्नेल यह नहीं जान सकता कि कौन सा डेटा सही है, तब भी जब एक गैर-अपमानित अवस्था में हो, क्योंकि केवल एक समानता है ब्लॉक और कोई रिपोर्ट नहीं थी। एक 3 डिस्क RAID1 या एक RAID6 में, एक भी भ्रष्ट गैर-URE- ध्वजांकित ब्लॉक निरर्थक समानता (अन्य संबद्ध ब्लॉकों के साथ संयोजन में) से मेल नहीं खाएगा, इसलिए उचित स्वचालित वसूली संभव होनी चाहिए।

कहानी का नैतिक है: ईसीसी के साथ ड्राइव का उपयोग करें। दुर्भाग्य से सभी ड्राइव जो ईसीसी का समर्थन नहीं करते हैं, इस सुविधा का विज्ञापन करते हैं। दूसरी ओर, सावधान रहें: मैं किसी ऐसे व्यक्ति को जानता हूं जिसने 2 डिस्क RAID1 (या एक 2 कॉपी RAID10) में सस्ते SSDs का उपयोग किया था। ड्राइव में से एक विशेष क्षेत्र के प्रत्येक रीड पर यादृच्छिक दूषित डेटा लौटाता है। दूषित डेटा स्वचालित रूप से सही डेटा पर कॉपी किया गया था। यदि एसएसडी ईसीसी का उपयोग करता है, और ठीक से काम कर रहा था, तो कर्नेल को उचित सुधारात्मक कार्रवाई करनी चाहिए थी।


1
मैंने सोचा कि सभी आधुनिक एचडीडी में आंतरिक ईसीसी का कुछ रूप है। यह प्रभावी है या नहीं, सही है, या खराबी एक और मामला है। URE को रिपोर्ट करने में सक्षम होने के लिए ड्राइव में आंतरिक रूप से ECC का उपयोग किया जाना है। साइलेंट बिट रोट, कि मुझे सबसे अधिक दिलचस्पी है, ड्राइव पर एक यूआरई की रिपोर्ट नहीं करता है जो इसका समर्थन करते हैं, क्योंकि उन्हें लगता है कि उनके पास सही डेटा है, जब वे नहीं करते हैं।
बेवुल्फ़नोडे42

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

1
अन्य समस्याओं के कारण बिट रॉट भी हो सकता है जैसे कि जब कुछ समस्या के कारण ड्राइव हेड्स को ठीक से एलाइन नहीं किया जा सकता है, जहां उसे लगता है कि यह लिख रहा है और यह आस-पास के सेक्टरों में फैल रहा है। यह उस क्षेत्र को ठीक कर सकता है जिस पर वह काम करना चाहता था, लेकिन पास के क्षेत्र को नुकसान होगा। यदि ऐसा होता है कि डेटा + ecc पर इस तरह से लिखा गया है कि पास के क्षेत्र के लिए ECC ठीक होने के रूप में रिपोर्ट करता है, तो ड्राइव को कभी पता नहीं चलेगा कि यह एक समस्या है। बहुत अधिक संभावना है, कुछ दुष्ट सॉफ़्टवेयर खराब डेटा लिखने के लिए ड्राइव का निर्देश देते हैं, एचडीडी विश्वासपूर्वक उस खराब डेटा को संग्रहीत करेगा। उदाहरण के लिए एक खराब dd कमांड
BeowulfNode42

2

आपके इच्छित सुरक्षा के लिए, मैं 2 स्थानों में RAID6 + सामान्य ऑफसाइट बैकअप के साथ जाऊंगा।

मैं व्यक्तिगत रूप से सप्ताह में एक बार स्क्रब करता हूं, और डेटा महत्व और परिवर्तन की गति के आधार पर रात, साप्ताहिक और मासिक बैकअप करता हूं।


1
लेकिन क्या बिट सड़ांध का पता लगाने / सुधार क्षमताओं कि पेशकश करता है?
BeowulfNode42

1
RAID6 लगातार स्क्रबिंग के साथ कुछ बिट-रोट सुरक्षा प्रदान करता है, क्योंकि डबल समता प्रभावी रूप से एक ही ब्लॉक के तीन संस्करण बनाती है, इसलिए "वोटिंग" किस संस्करण पर आयोजित किया जा सकता है। AFAIK, RAID6 लिनक्स dm-छापे में स्क्रबिंग बस यही करता है, कृपया मुझे सही करें अगर मैं गलत हूं।
पी।

1
@ पी। मुझे पता है कि गणित में शामिल COULD एक मतदान प्रणाली का उपयोग करता है, लेकिन क्या mdadm करता है? क्या आप इसके बारे में किसी भी दस्तावेज के बारे में जानते हैं या आपके पास व्यक्तिगत अनुभव है जो आपको इस निष्कर्ष पर ले गया है। विशेष रूप से एतान के उत्तर के प्रकाश में।
बियोवुल्फ़नोडे42

यह कुछ समय पहले था, लेकिन मैं टिप्पणी करने से पहले mdadm RAID6 तंत्र पर पढ़ने को याद करता हूं। क्षमा करें, बहुत विशिष्ट नहीं है। :( मुझे लगता है कि हम mdadm पर एक वास्तविक विशेषज्ञ का उपयोग कर सकते हैं ...
P.Péter

2

मेरे पास टिप्पणी करने के लिए पर्याप्त प्रतिनिधि नहीं है, लेकिन मैं यह बताना चाहता हूं कि लिनक्स में mdadm प्रणाली किसी भी त्रुटि को ठीक नहीं करती है। यदि आप इसे रबड के दौरान त्रुटियों को "ठीक" करने के लिए कहते हैं, तो RAID6 कहें, अगर कोई असंगति है, तो यह डेटा भागों को सही मानते हुए और समता को पुन: परिकलित करके इसे "ठीक" करेगा।


1
ऐसा लगता है कि जब तक मैं आपको गलत नहीं समझता, यह संभावना नहीं है। क्या आपका मतलब है कि भ्रष्ट ब्लॉकों के डेटा को अक्सर सही ब्लॉकों पर कॉपी किया जाता है? इसके लिए आवश्यक है कि खराब ब्लॉक एक ऐसे ड्राइव से नहीं आए जो ECC को सपोर्ट करता हो (और इस तरह URE को रिपोर्ट नहीं करेगा), और यह कि आप RAID5 या 2 कॉपी RAID1 का उपयोग कर रहे हैं (इसके बजाय RAID6 जैसा आपने सुझाव दिया है।)
sudoman

@sudoman, एक स्क्रब के दौरान, यदि लिनक्स एमडी सबसिस्टम डेटा और समता के बीच एक बेमेल का पता लगाता है, तो यह आँख बंद करके मानता है कि समता गलत है और डेटा के आधार पर इसे फिर से लिखता है। यह पता लगाने के लिए कि यह गलत है, RAID 6 की डबल-समता का उपयोग करना संभव है, लेकिन लिनक्स एमडी सबसिस्टम ऐसा नहीं करता है।
मार्क

1
एथन, मुझे नहीं लगता कि आपके पास इस जानकारी के लिए कोई संदर्भ है? या व्यक्तिगत अनुभव के उदाहरण आप साझा करने के लिए तैयार हैं जो आपको याद है? यह क्यू उत्पन्न किया गया tumbleweeds को देखते हुए, यहां तक ​​कि वास्तविक जानकारी उपयोगी होगी। चूंकि यह Q पोस्ट किया गया था इसलिए मुझे बूट ड्राइव के लिए mdadm RAID1 के साथ कुछ समस्याएँ हुईं, जब उनमें से 1 खराब हो गया था (सस्ते) USB स्टिक पर। कुछ जांच बाद में उस असफल छड़ी की ओर इशारा करती है जिसमें पर्याप्त या कोई त्रुटि जाँच नहीं होती है, या यह केवल कुछ ब्लॉकों में डेटा लिखने और लेखन त्रुटि का उत्पादन नहीं करने में विफल रही है। मुझे ओएस को फिर से स्थापित करना पड़ा।
बेवुल्फनोडे42

-2

थोड़ा सड़ांध। ज़रूर...

मुझे लगता है कि आपको SEAGATE से बात करने की आवश्यकता है। (भूल जाओ? यह बहाना है)? ड्राइव अब सभी 100bit ECC सुधार आप पहले सड़ांध साबित करने की जरूरत है।
मुझे यकीन है आप नहीं कर सकते। (यह सही चिंता करने के लिए FUD बात है?) भूत या # 13 के डर की तरह? और यहाँ नहीं किया। जीरो प्रूफ हुआ। और कारण का कोई बुरा सबूत।

पहले परिभाषित करें कि बिट रॉट का मतलब क्या है। ouch ... एचडीडी: ईसीसी ईसीसी 100 बिट स्टोरेज के खिलाफ डेटा (यहां तक ​​कि 1 बिट) की जांच करता है। यदि यह गलत है, तो यह इसे सही करता है, अगर यह स्मार्ट ड्राइव को विफल कर रहा है, तो एसएएस ड्राइव पर सुनिश्चित करने के लिए, यह तार्किक रूप से क्लस्टर या सेक्टर को एक के साथ बदल देता है जो अच्छा है। अतिरिक्त कलस्टर का उपयोग करना। यह क्षति की मरम्मत करता है। हाँ सभी ड्राइव आईबीएम फर्स्ट ड्राइव से नाउ तक एक दिन से लेकर अंत तक खराब बिट्स बढ़ते हैं। लेकिन अब हम स्वयं की मरम्मत करते हैं, पूर्ण सीगेट श्वेत पत्र पढ़ें। वहाँ अंतहीन, और जानें कि एक ड्राइव कैसे काम करता है। ठीक?

यह तब तक चलता रहता है जब तक कि आप पुर्जों (HDD दिमाग, स्मार्ट) से बाहर नहीं निकल जाते हैं और फिर जीवन के अंत में स्मार्ट चिल्लाते हैं। (या इससे भी अधिक प्रारंभिक, जैसे एचपी करता है) एचपी पी 420 नियंत्रक कहते हैं, यह हर समय देखता है। मेरा यहां तक ​​कि मुझे ईमेल, दूर के समूहों की जरूरत है। शायद ही कभी पुर्जों को तेजी से आगे बढ़ता है, जल्द ही कयामत का एक निश्चित संकेत, (10 साल पुराना सास यकीनन, कम से कम कबाड़ साटा में।

मैं BOGUS को बुलाता हूं, और बिट रोट पर FUD।

मेरा अनुमान है कि किसी ने खिलौना पीसी ने डेटा को गलत लिखा है, कभी किन कारणों से। ईसीसी मेमोरी नहीं चल रहा है ?? ओह, असली सर्वर में ECC RAM है। वायरस संक्रमित? या लेखन के दौरान खोई हुई शक्ति (कोई यूपीएस>?)? या बुरी याददाश्त है। या ESD क्षतिग्रस्त। या PSU टन टन शोर (खराब)

मुझे यहां FUD कहते हैं। माफ़ करना,


1
मैंने अभी स्पष्ट किया है कि मैं अपने होम सिस्टम के बारे में बात कर रहा था, इसलिए ईसीसी और सर्वर ग्रेड हार्डवेयर मेरे बजट मूल्य सीमा से बाहर है। मेरा होम लैब अपने मिनी अप्स या अन्य रैंडम इवेंट्स जैसे कि टॉवर के ऊपर या किसी चीज के गिरने से भी अनपेक्षित पावर लॉस की अधिक संभावना है। HDD के लिए गलत डेटा स्टोर करने के लिए बहुत सारे तरीके बताए गए हैं और उस गलत डेटा के लिए ECC बिट्स को HDD स्टोर करना है। मुझे परवाह नहीं है कि त्रुटियां कैसे हुईं, मैं चाहता हूं कि वे आसानी से तय हो जाएं।
बेवुल्फ़नोडे42
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.