क्या हार्ड ड्राइव पर सड़ांध एक वास्तविक समस्या है? इस विषय में क्या किया जा सकता है?

Question

एक दोस्त मेरे साथ बिट रोट की समस्या के बारे में बात कर रहा है - ड्राइव पर बेतरतीब ढंग से फ़्लिप करना, डेटा को भ्रष्ट करना। अविश्वसनीय रूप से दुर्लभ, लेकिन पर्याप्त समय के साथ यह एक समस्या हो सकती है, और इसका पता लगाना असंभव है।

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

क्या यह वास्तविक समस्या है? और यदि हां, तो इसके बारे में क्या किया जा सकता है? मेरे दोस्त एक समाधान के रूप में zfs की सिफारिश कर रहे हैं, लेकिन मैं काम पर हमारे फ़ाइल सर्वरों को समतल करने की कल्पना नहीं कर सकता, सोलारिस और ज़ेड ..

Comments

इस पर एक लेख यहाँ है: web.archive.org/web/20090228135946/http://www.sun.com/bigadmin/…

— scobi

मैं सिर्फ एक पुराने 200GB Seagate डिस्क पर एक अच्छा स्मार्ट त्रुटि फसल था। बिट्स, उन्होंने बहुत अधिक रोटी दी है :-( यह 5 साल की वारंटी से छह महीने छोटा है, इसलिए मुझे शायद बहुत उपद्रव के बिना प्रतिस्थापन मिल जाएगा।

— ThatGraemeGuy

Answer 1

पहले बंद: आपकी फ़ाइल प्रणाली में चेकसम नहीं हो सकते हैं, लेकिन आपकी हार्ड ड्राइव में ही उनके पास है। उदाहरण के लिए स्मार्ट है। एक बार एक बिट बहुत अधिक फ़्लिप हो गया, तो त्रुटि को ठीक नहीं किया जा सकता है, निश्चित रूप से। और अगर आप वास्तव में बदकिस्मत हैं, तो बिट्स इस तरह से बदल सकते हैं कि चेकसम अमान्य नहीं हो जाएगा; तब त्रुटि का भी पता नहीं चलेगा। तो, बुरा काम हो सकता है; लेकिन दावा है कि एक यादृच्छिक बिट फ़्लिपिंग आपको भ्रष्ट कर देगा डेटा फर्जी है।

हालाँकि, हाँ, जब आप हार्ड ड्राइव पर खरबों बिट्स डालते हैं, तो वे हमेशा के लिए नहीं रहेंगे; यह एक वास्तविक समस्या है! हर बार डेटा पढ़ने पर ZFS अखंडता की जाँच कर सकता है; यह वही है जो आपकी हार्ड ड्राइव पहले से ही करती है, लेकिन यह एक अन्य सुरक्षा उपाय है जिसके लिए आप कुछ स्थान का त्याग कर रहे हैं, इसलिए आप डेटा भ्रष्टाचार के खिलाफ लचीलापन बढ़ा रहे हैं।

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

किसी भी तरह से: नहीं, यह पता लगाना असंभव नहीं है ।

लेकिन एक फ़ाइल सिस्टम, अपने आप में, कभी भी इस बात की गारंटी नहीं हो सकती है कि हर विफलता से उबर लिया जा सकता है; यह चांदी की गोली नहीं है। त्रुटि का पता चलने पर आपके पास बैकअप और एक योजना / एल्गोरिथ्म होना चाहिए।

Comments

ठीक है, विकिपीडिया ( en.wikipedia.org/wiki/Error_detection_and_correction ) के अनुसार आधुनिक हार्ड ड्राइव त्रुटियों का पता लगाने और कॉम्पैक्ट डिस्क शैली त्रुटि सुधार का उपयोग करके पुनर्प्राप्त करने का प्रयास करने के लिए सीआरसी का उपयोग करते हैं। मेरे लिए यह काफी अच्छा है।

— scobi

लेकिन अगर CRC को उसी स्थान (सेक्टर) में संग्रहीत किया जाता है, तो यह डेटा सभी त्रुटि मामलों के लिए मदद नहीं करेगा। उदाहरण के लिए, यदि कोई हेड पोजिशनिंग एरर डेटा गलत सेक्टर को लिखा जा सकता है - लेकिन एक सही चेकसम => के साथ आप समस्या का पता नहीं लगा पाएंगे। यही कारण है कि ZFS में चेकसम को उनके द्वारा संरक्षित डेटा से अलग से संग्रहीत किया जाता है।

— क् 8

क्या ZFS के पास अब विंडोज जैसा रखरखाव है? यह मूल रूप से चुंबकीय कोडिंग को ताज़ा करने के लिए नियमित रूप से डेटा को फिर से लिखता है।

— टॉमटॉम

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

— जोड़ी ली ब्रूचोन

@JodyLeeBruchon अब आपको मुख्य रूप से हैमिंग कोड पर एक स्रोत मिल गया है? हाल ही में मैं जो जानकारी जुटा रहा हूं, उसने संकेत दिया है कि ड्राइव निर्माता अभी भी सीआरसी-आरएस का उपयोग कर रहे हैं। 1 2

— इयान शूनओवर

Answer 2

हाँ यह एक समस्या है, मुख्य रूप से ड्राइव के आकार के ऊपर जाने के कारण। अधिकांश SATA ड्राइव में 10 ^ 14 की URE (अचूक रीड एरर) दर है। या हर 12TB डेटा के लिए सांख्यिकीय रूप से ड्राइव वेंडर कहता है कि ड्राइव रीड फेल लौटा देगा (आप सामान्यतया ड्राइव स्पेक शीट पर देख सकते हैं)। ड्राइव ड्राइव के अन्य सभी भागों के लिए ठीक काम करना जारी रखेगा। एंटरप्राइज एफसी और एससीएसआई ड्राइव में आमतौर पर 10 ^ 15 (120TB) की URE दर होती है, साथ ही SATA ड्राइव की एक छोटी संख्या होती है जो इसे कम करने में मदद करती है।

मैंने कभी भी डिस्कों को ठीक उसी समय पर घूमना बंद नहीं किया है, लेकिन मैंने इस मुद्दे पर एक छापे की मात्रा 5 मारा है (5 साल पहले 5400RPM उपभोक्ता पाटा ड्राइव के साथ)। ड्राइव विफल हो जाता है, यह मृत हो जाता है और अतिरिक्त ड्राइव पर एक पुनर्निर्माण होता है। समस्या यह है कि पुनर्निर्माण के दौरान एक दूसरा ड्राइव डेटा के एक छोटे से ब्लॉक को पढ़ने में असमर्थ है। छापेमारी करने के आधार पर पूरी मात्रा मृत हो सकती है या बस थोड़ा ब्लॉक मृत हो सकता है। यह मानते हुए कि केवल एक ब्लॉक मृत है, यदि आप इसे पढ़ने की कोशिश करते हैं तो आपको एक त्रुटि मिलेगी लेकिन यदि आप इसे लिखते हैं तो ड्राइव इसे दूसरे स्थान पर फिर से भेज देगा।

रक्षा करने के लिए कई तरीके हैं: raid6 (या समतुल्य) जो डबल डिस्क विफलता से बचाता है, सबसे अच्छा है, अतिरिक्त लोग ZFS जैसे एक URE जागरूक फाइल सिस्टम हैं, छोटे छापे समूहों का उपयोग करते हुए इसलिए सांख्यिकीय रूप से आपके पास URE ड्राइव मारने की संभावना कम है सीमाएं (मिरर लार्ज ड्राइव या रेड 5 ड्राइव), डिस्क स्क्रबिंग और स्मार्ट भी मदद करता है, लेकिन वास्तव में अपने आप में एक सुरक्षा नहीं है, लेकिन उपरोक्त विधियों में से एक के अतिरिक्त इसका उपयोग किया जाता है।

मैं सरणियों में लगभग 3000 स्पिंडल का प्रबंधन करता हूं, और एरे लगातार अव्यक्त यूआरई की तलाश में ड्राइव को स्क्रब कर रहा है। और मैं उनमें से एक काफी निरंतर स्ट्रीम प्राप्त करता हूं (हर बार जब यह पाता है कि यह ड्राइव विफलता के आगे इसे ठीक करता है और मुझे अलर्ट करता है), अगर मैं raid6 के बजाय raid5 का उपयोग कर रहा था और ड्राइव में से एक पूरी तरह से मृत हो गया ... मैं अगर यह कुछ स्थानों को हिट करता है तो मुसीबत में पड़ सकता है।

Comments

आप किन इकाइयों में बोल रहे हैं? "10 ^ 14" एक "दर" नहीं है।

— जय सुलिवन

यह इकाई "10 ^ 14 बिट्स प्रति त्रुटि पढ़ें" होगी, जो 12 टीबी प्रति त्रुटि पढ़ने के बराबर होगी।

— जो लिस

और निश्चित रूप से, यह ध्यान में रखते हुए कि त्रुटि दर आम तौर पर बिट्स के प्रति पूर्ण क्षेत्र त्रुटियों के संदर्भ में उद्धृत की जाती है। इसलिए जब कोई निर्माता URE दरों को 10 ^ -14 पर बताता है, तो उनका वास्तव में क्या मतलब है कि किसी भी यादृच्छिक क्षेत्र की URE को पढ़ने की संभावना 10 ^ -14 है और यदि ऐसा होता है, तो पूरा क्षेत्र अपठनीय के रूप में वापस आता है। वह और तथ्य यह है कि यह आंकड़े हैं; वास्तविक दुनिया में, UREs बैचों में आते हैं।

— बजे एक CVn

Answer 3

हार्ड ड्राइव आम तौर पर डेटा बिट्स को सिंगल मैग्नेटिक डोमेन के रूप में एनकोड नहीं करते हैं - हार्ड ड्राइव निर्माताओं को हमेशा पता होता है कि मैग्नेटिक डोमेन फ्लिप कर सकता है, और ड्राइव्स में एरर डिटेक्शन और करेक्शन का निर्माण कर सकता है।

यदि थोड़ा सा फ़्लिप किया जाता है, तो ड्राइव में पर्याप्त निरर्थक डेटा होता है जो अगली बार उस सेक्टर को पढ़ने के बाद ठीक किया जा सकता है। यदि आप ड्राइव पर SMART आँकड़े जाँचते हैं, तो आप इसे 'सुधारात्मक त्रुटि दर' के रूप में देख सकते हैं।

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

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

Comments

वास्तव में, मेरे पास नियमित रूप से बिट-रोट एरर्स हैं (भागों में मैं ज्यादा नहीं पढ़ता), जो सिस्टम चुपचाप (गलत तरीके से) से ठीक हो जाता है। यदि कम से कम यह मुझे सूचित करता है कि बिट-रोट था, तो मैं इसे पुनर्प्राप्त करने से पहले इसे पुनर्प्राप्त करने के लिए डेटा को फिर से पढ़ सकता था; और अगर अप्राप्य है, तो मैं इसे अन्य हार्ड ड्राइव से तुलना करने में सक्षम हूं।

— एलेक्स

एलेक्स, कृपया अपने एचडीडी स्मार्ट डेटा और सिस्टम रैम की जांच करें कि यह पुष्टि करने के लिए कि भ्रष्टाचार के कारण कोई अन्य समस्या नहीं है। बिट रोट / यादृच्छिक भ्रष्टाचार अत्यंत दुर्लभ है, इसलिए आपकी मशीन के साथ कुछ और हो सकता है।

— ब्रायन डी।

@BrianD। एक मुद्दा यह था, मैंने हार्ड ड्राइव को उनके (अछूता) पैकिंग सामग्री के अंदर रखा था; यह काम करते हुए 60 डिग्री सेल्सियस से अधिक की गर्मी का कारण बन रहा था, अंत में दिनों के लिए। क्या वह ध्वनि एक वैध कारण की तरह है, जिसके कारण बिट रोट हो सकता है?

— एलेक्स

यह निश्चित रूप से अनुशंसित नहीं है, क्योंकि अधिकांश एचडीडी में छोटे वायु छेद हैं, जिन्हें ठीक से संचालित करने के लिए कवर नहीं किया जाना चाहिए। चाहे आपका मुद्दा थोड़ा सड़ गया हो या कुछ और, मैं सही ढंग से काम कर रहा है सब कुछ सत्यापित करने के लिए पीसी पर एक पूर्ण नैदानिक ​​चलाएगा।

— ब्रायन डी।

Answer 4

आधुनिक हार्ड ड्राइव (199x के बाद से) में न केवल चेकसम हैं, बल्कि ईसीसी भी है, जो थोड़ा सा "यादृच्छिक" बिट रॉट का पता लगा सकता है और सही कर सकता है। देखें: http://en.wikipedia.org/wiki/SMART ।

दूसरी ओर, फर्मवेयर और डिवाइस ड्राइवर में कुछ बग दुर्लभ (अन्यथा क्यूए बग को पकड़ेंगे) अवसरों में डेटा को भ्रष्ट कर सकते हैं, जो यह पता लगाने के लिए कठिन होगा कि क्या आपके पास उच्च स्तर के चेकसम नहीं हैं। SATA और NIC के शुरुआती डिवाइस ड्राइवरों ने लिनक्स और सोलारिस दोनों पर डेटा को दूषित कर दिया था।

जेडएफएस चेकसम ज्यादातर निचले स्तर के सॉफ़्टवेयर में बग का लक्ष्य रखते हैं। हाइपरटेबल जैसे नए स्टोरेज / डेटाबेस सिस्टम में फाइल सिस्टम में बग्स से बचाव के लिए हर अपडेट के लिए चेकसम हैं :)

Answer 5

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

जब तक आप बिट्स के साथ काम कर रहे होते हैं जो संभावित रूप से किसी के मस्तिष्क को रोक सकते हैं , मुझे यकीन नहीं है कि जोखिम बनाम इनाम फ़ाइल सिस्टम को बदलने के बिंदु तक काफी है।

Comments

मैं यह नहीं देखता कि बच्चे / माता-पिता / दादा-दादी बैकअप कैसे मदद करते हैं। उस सिस्टम के साथ पता करने का कोई तरीका नहीं है अगर थोड़ा फ़्लिप किया जाता है क्योंकि एक उपयोगकर्ता इसे बदलने का इरादा रखता है या अगर ड्राइव ने इसे अपने दम पर किया है। बिना किसी तरह के चेकसम के नहीं।

— scobi

यदि आपके पास डेटा अच्छा नहीं है, तो कई बैकअप लेने से मदद नहीं मिलेगी। आप मैन्युअल रूप से अपनी फ़ाइलों को चेकसम कर सकते हैं, लेकिन ZFS बहुत अधिक स्वचालित रूप से करता है और फाइल सिस्टम प्रबंधन को आसान बनाता है।

— आमोक

एक हफ़्ते / महीने से अधिक समय तक बैकअप रखने वाले फ़ाइल की एक अच्छी प्रतिलिपि होने की संभावना बढ़ जाती है। मैं शायद उस बारे में स्पष्ट हो सकता था।

— कारा मार्फिया

समस्या यह है: आप कैसे जानते हैं कि आपके पास एक खराब प्रतिलिपि है? और आपको कैसे पता चलेगा कि कौन सी कॉपी बैकअप है जो अच्छी है? स्वचालित तरीके से।

— स्कोबी

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

— कारा मरफिया

Answer 6

हाँ यह एक समस्या है।

यह एक कारण है कि RAID6 अब प्रचलन में है (साथ ही साथ HD आकार में वृद्धि एक सरणी के पुनर्निर्माण के लिए समय बढ़ाती है)। दो समता वाले ब्लॉक होने से अतिरिक्त बैकअप की अनुमति मिलती है।

RAID सिस्टम अब RAID स्क्रबिंग भी करते हैं, जो समय-समय पर डिस्क ब्लॉक, पैरिटीज के खिलाफ चेक पढ़ता है, और अगर यह ब्लॉक को खराब पाता है तो इसे बदल देता है।

Comments

सावधान रहें, डेटा अखंडता सभी RAID सिस्टम की विशेषता नहीं है।

— duffbeer703

टेराबाइट ड्राइव के साथ, भाग्य को साझा करने वाले बहुत सारे बिट हैं, और बिट का भौतिक भंडारण क्षेत्र इतना छोटा है, कि यह समस्या अधिक महत्वपूर्ण हो जाती है। उसी समय, विफलता की संभावना टेराबाइट ड्राइव के साथ इतनी बढ़ जाती है कि RAID6 पर्याप्त नहीं है जब तक कि आप पूल में बहुत सारे ड्राइव नहीं डाल रहे हैं, 8 या अधिक कहें। छोटी संख्या में ड्राइव के साथ दर्पण उर्फ ​​RAID 10 का उपयोग करना बेहतर होता है। दोनों RAID 6 (raidz2) और RAID 10 (zpool बनाएँ mypool दर्पण c0t1d0 c0t2d0 दर्पण c0t3d0 c0t4d0) ZFS पर संभव हैं।

— माइकल डिलन

RAID यह नहीं बता सकता है कि कौन सा डेटा अच्छा है और ऐसा नहीं है इसलिए यह त्रुटियों को ठीक नहीं कर सकता है, यह सिर्फ उनका पता लगा सकता है।

— अमोक

Amuck: "RAID स्टैण्डर्ड" के भाग के अनुसार नहीं, प्रति se, लेकिन उन्नत RAID सिस्टम (फ़र्मवेयर, इत्यादि) ऐसा करते हैं

— मैट रोजिश

@ माइकल डिलिन - RAID6 विश्वसनीयता नहीं बढ़ती है क्योंकि आप ड्राइव की संख्या बढ़ाते हैं। सभी डेटा के लिए केवल मूल डेटा + 2 समता है। बढ़ती ड्राइव संख्या विश्वसनीयता के लिए बदतर है क्योंकि यह किसी भी डेटा की अनावश्यकता में वृद्धि के बिना संभव ड्राइव विफलता दर को बढ़ाता है। ड्राइव नंबर बढ़ाने का एकमात्र कारण, आपके उपलब्ध संग्रहण आकार को बढ़ाना है।

— ब्रायन डी।

Answer 7

RAID के बारे में ओपी के बयान के संबंध में समझ नहीं आ रहा है कि क्या डेटा अच्छा बनाम बुरा है।

RAID नियंत्रक डेटा के प्रत्येक स्ट्रिप पर बहुत कम (विषम / सम) समता बिट्स का उपयोग करते हैं। यह सब कुछ के लिए है; डेटा-ऑन-डिस्क धारियाँ और समता (बैकअप) डेटा धारियाँ।

इसका मतलब यह है कि किसी भी RAID प्रकार के लिए जिसमें अतिरेक (RAID 5/6) के लिए स्ट्रिपिंग है, नियंत्रक सटीक रूप से बता सकता है कि क्या मूल डेटा पट्टी बदल गई है, साथ ही, यदि अतिरेक डेटा पट्टी बदल गई है।

यदि आप RAID6 जैसी दूसरी निरर्थक पट्टी पेश करते हैं, तो आपके पास 3 डेटा स्ट्रिप्स होना चाहिए, तीन अलग-अलग ड्राइवों पर भ्रष्ट हो जाते हैं, जो सभी एक ही वास्तविक फ़ाइल डेटा के अनुरूप होते हैं। याद रखें कि अधिकांश RAID सिस्टम अपेक्षाकृत छोटे डेटा धारियों (128kb या उससे कम) का उपयोग करते हैं इसलिए "बिट रोट" की संभावना एक ही फाइल के लिए 128kb तक समान बिटकॉइन के लिए व्यावहारिक रूप से असंभव है।

Answer 8

यह एक वास्तविक दुनिया की समस्या है, हाँ, लेकिन सवाल यह है कि क्या आपको इसके बारे में चिंता करनी चाहिए या नहीं।

यदि आपको केवल चित्रों से भरा एक hdd मिला है तो यह प्रयास के लायक नहीं हो सकता है। यह महत्वपूर्ण वैज्ञानिक डेटा से भरा है, यह एक अन्य प्रकार की कहानी हो सकती है, आपको यह विचार मिला।