मूक डिस्क त्रुटियों और लिनक्स स्वैप की विश्वसनीयता

Question

मेरी समझ यह है कि हार्ड ड्राइव और एसएसडी ड्राइव के अंदर कुछ बुनियादी त्रुटि सुधार को लागू करते हैं, और अधिकांश RAID कॉन्फ़िगरेशन जैसे mdadm यह तय करने के लिए निर्भर करेगा कि ड्राइव कब त्रुटि को ठीक करने में विफल रही है और उसे ऑफ़लाइन लेने की आवश्यकता है। हालाँकि, यह संग्रहण पर निर्भर करता है कि इसकी त्रुटि निदान में 100% सटीक है। ऐसा नहीं है, और एक दो-ड्राइव RAID-1 दर्पण की तरह एक सामान्य कॉन्फ़िगरेशन कमजोर होगा: मान लीजिए कि एक ड्राइव पर कुछ बिट्स चुपचाप दूषित हैं और ड्राइव एक रीड त्रुटि की रिपोर्ट नहीं करता है। इस प्रकार, फ़ाइल सिस्टम जैसे btrfs और ZFS अपने स्वयं के चेकसमों को लागू करते हैं, ताकि बगगी ड्राइव फ़र्मवार, ग्लिची एसएटीए केबल्स और इतने पर भरोसा न करें।

इसी तरह, RAM में भी विश्वसनीयता की समस्या हो सकती है और इस प्रकार इस समस्या को हल करने के लिए हमारे पास ECC RAM है।

मेरा सवाल यह है : दो-डिस्क कॉन्फ़िगरेशन (यानी मेनलाइन कर्नेल ड्राइवरों का उपयोग करके) पर ड्राइव फर्मवेयर द्वारा मूक भ्रष्टाचार / बिट रोट से लिनक्स स्वैप फ़ाइल की रक्षा के लिए विहित तरीका क्या है? यह मुझे लगता है कि एक कॉन्फ़िगरेशन जिसमें यहां एंड-टू-एंड प्रोटेक्शन का अभाव है (जैसे कि btrfs द्वारा प्रदान किया गया है) कुछ हद तक ECC RAM द्वारा लाई गई मन की शांति को नकारता है। फिर भी मैं अच्छे तरीके से नहीं सोच सकता:

• btrfs स्वैफ़ाइल्स का समर्थन बिल्कुल नहीं करता है। आप एक btrfs फ़ाइल से एक लूप डिवाइस सेट कर सकते हैं और उस पर एक स्वैप बना सकते हैं। लेकिन यह समस्या है:
  • रैंडम राइट्स अच्छा प्रदर्शन नहीं करते हैं: https://btrfs.wiki.kernel.org/index.php/Gotchas#Fragmentation
  • कॉपी-ऑन-राइट को अक्षम करने का सुझाव भी चेकसमिंग को अक्षम करेगा - इस प्रकार इस अभ्यास के पूरे बिंदु को हरा देगा। उनकी धारणा है कि डेटा फ़ाइल के अपने आंतरिक सुरक्षा हैं।
• लिनक्स पर ZFS स्वैप के रूप में एक ZVOL का उपयोग करने की अनुमति देता है, जो मुझे लगता है कि काम कर सकता है: http://zfsonlinux.org/faq.html#CanIUseaZVOLforSwap - हालांकि, मेरे पढ़ने से, ZFS सामान्य रूप से स्मृति में मांग कर रहा है, और इसे स्वैप में काम कर रहा है। -एक आवेदन लगता है जैसे कुछ काम यह समझ से बाहर। मुझे लगता है कि यह मेरी पहली पसंद नहीं है। आपको केवल विश्वसनीय स्वैप होने के लिए कुछ आउट-ऑफ-ट्री कर्नेल मॉड्यूल का उपयोग क्यों करना पड़ेगा - निश्चित रूप से इस दिन और उम्र में सबसे आधुनिक लिनक्स वितरण / गुठली के साथ इसे पूरा करने का एक तरीका है?
• वास्तव में स्मृति प्रबंधक के भीतर चेकसमों को सक्षम करने के लिए पैच के साथ एक लिनक्स कर्नेल मेलिंग सूची पर एक धागा था, इस सवाल में जिन कारणों से मैं चर्चा करता हूं, उनके लिए: http://thread.gmane.org/gmane.linux.kernel/9th246 - दुर्भाग्य से, जहां तक ​​मैं बता सकता हूं, पैच मर गया और कभी भी मेरे लिए अज्ञात कारणों से यह ऊपर की ओर नहीं बना। बहुत बुरा, यह एक अच्छी सुविधा की तरह लग रहा था। दूसरी ओर, यदि आप RAID-1 पर स्वैप डालते हैं - यदि भ्रष्टाचार मरम्मत करने के लिए चेकसम की क्षमता से परे है, तो आप चाहते हैं कि मेमोरी मैनेजर पैन करने से पहले या जो भी हो, दूसरे ड्राइव से पढ़ने की कोशिश करे, जो शायद स्मृति प्रबंधक को क्या करना चाहिए, इसके दायरे से बाहर।

संक्षेप में:

• RAM में त्रुटियों को सुधारने के लिए ECC है
• स्थायी संग्रहण की फ़ाइलों में त्रुटियों को ठीक करने के लिए btrfs हैं
• स्वैप है ??? <--- यह मेरा सवाल है

Comments

एन्क्रिप्टेड स्वैप क्या साइड-इफेक्ट के रूप में त्रुटि का पता नहीं लगाएगा? यदि एन्क्रिप्टेड स्ट्रीम ड्राइव पर दूषित है, तो डिक्रिप्शन उड़ जाएगा ... मुझे नहीं पता कि सिस्टम फिर कैसे प्रतिक्रिया करता है!

— स्टीफन किट

मुझे btrfs से कोई अनुभव नहीं है, लेकिन मैंने आपके द्वारा उद्धृत लिंक को पढ़ा है, और मुझे लगता है कि आप कुछ देख रहे हैं। वे उन फाइलों का जिक्र कर रहे हैं जिनमें ब्लॉक गतिशील रूप से बनाए गए हैं, यानी विरल फाइलें। आप एक समर्पित brtfs विभाजन बना सकते हैं, बिना गाय पर चढ़े, अपने वांछित स्वैप आकार से मेल खाते हुए शून्य (dd if = / dev / zero) से भरी फ़ाइल बनाएँ, और उस फ़ाइल को स्वैप के रूप में माउंट करें। मुझे कोई कारण नहीं दिखता कि इससे प्रदर्शन पर जुर्माना क्यों लगेगा।

— ओथियस

@ प्रदर्शन के कारणों के लिए एमडी केवल एक डिवाइस से पढ़ता है (अधिक सटीक रूप से, यह सभी उपकरणों से पढ़ता है, लेकिन एक एकल रीड में केवल एक डिवाइस शामिल होता है); इसमें शामिल सभी उपकरणों की सामग्री की तुलना की जा सकती है, लेकिन यह एक अलग ऑपरेशन, स्क्रबिंग है ।

— स्टीफन किट

@Otheus: nodatacow को सेट करना भी चेकसम को अक्षम करता है: btrfs.wiki.kernel.org/index.php/Mount_options ... "यह चेकसमिंग को भी बंद कर देता है! IOW, nodatacum का अर्थ है नोडोडासम।" ..... nodatasum कहते हैं: "मतलब बिट्स" फ़्लिप और बिट रोट अनडेटेड हो सकते हैं। "

— जेम्स जॉनसन

@Otheus: "आखिरकार, गैर एसडीडी डिस्क के साथ, प्रत्येक 512 या 1k ब्लॉक में एक सीआरसी जुड़ा होता है" .... सच है, लेकिन यह डिस्क के बाहर बिट फ़्लिप के खिलाफ की रक्षा नहीं करेगा। (और आप बंद-स्रोत एक-बंद स्वामित्व ड्राइव फर्मवेयर में बहुत अधिक विश्वास भी रखते हैं।) ये कारण हैं कि btrfs और ZFS पहले स्थान पर मौजूद हैं: वे अंतर्निहित भंडारण पर भरोसा नहीं करते हैं (अन्यथा वे परेशान नहीं करेंगे। पहले स्थान पर चेकसमिंग के साथ)। उदाहरण के लिए, कुछ उपयोगकर्ताओं ने खराब SATA केबलिंग और / या परतदार बिजली आपूर्ति के कारण बिट फ़्लिप की सूचना दी है।

— जेम्स जॉनसन

Answer 1

हम स्वैप से पुनर्प्राप्त डेटा की अखंडता पर भरोसा करते हैं क्योंकि भंडारण हार्डवेयर में चेकसम, सीआरसी और ऐसे हैं।

उपरोक्त टिप्पणियों में से एक में, आप कहते हैं:

यह सच है, लेकिन यह डिस्क के बाहर बिट फ़्लिप के खिलाफ की रक्षा नहीं करेगा

"यह" डिस्क के चेकसम का अर्थ है।

यह सच है, लेकिन SATA कमांड और डेटा के लिए 32-बिट सीआरसी का उपयोग करता है । इस प्रकार, आपके पास डिस्क और SATA नियंत्रक के बीच डेटा को भ्रष्ट करने की संभावना 1 से 4 बिलियन है। इसका मतलब है कि एक निरंतर त्रुटि स्रोत एक त्रुटि को पेश कर सकता है जैसा कि प्रत्येक 125 MiB हस्तांतरित करता है, लेकिन एक दुर्लभ, यादृच्छिक त्रुटि स्रोत जैसे ब्रह्मांडीय किरणें गायब हो जाने वाली छोटी दर पर अवांछनीय त्रुटियों का कारण बन सकती हैं।

यह भी महसूस करें कि यदि आपको कोई ऐसा स्रोत मिल गया है, जो प्रति 125 MiB हस्तांतरित के पास कहीं भी एक दर पर एक अनिर्धारित त्रुटि का कारण बनता है, तो पुन: स्थानांतरण की आवश्यकता वाले उच्च त्रुटियों का पता लगाने के कारण प्रदर्शन भयानक होगा । निगरानी और लॉगिंग शायद आप समय में समस्या के प्रति सचेत करेंगे ताकि आप अनचाहे भ्रष्टाचार से बच सकें।

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

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

एक अन्य टिप्पणी में, आप पूछते हैं:

अगर SATA इतना भरोसेमंद है, तो ZFS, btrfs, ReFS जैसी चेकसम फाइल सिस्टम क्यों हैं?

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

उस के ऊपर, आम तौर पर कई वर्षों में उतार-चढ़ाव कम हो गए हैं, कर्नेल और libcअपडेट की वर्धित आवृत्ति , वर्चुअलाइजेशन, क्लाउड आर्किटेक्चर आदि के साथ क्या हुआ ।

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

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

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

इसका मतलब यह है कि आपको एक विश्वसनीय स्वैप डिवाइस का उपयोग करना चाहिए। मैंने एक बार बीमार ZFS पूल को बचाने के लिए एक $ 20 बाहरी USB HDD बाड़े का उपयोग किया था, केवल यह पता लगाने के लिए कि यह संलग्नक स्वयं अविश्वसनीय था, इस प्रक्रिया में स्वयं की त्रुटियों का परिचय देता है। ZFS की मजबूत जाँच ने मुझे यहाँ बचाया। आप एक स्वैप फ़ाइल के साथ भंडारण मीडिया के इस तरह के इलाज से दूर नहीं हो सकते। यदि स्वैप डिवाइस मर रहा है, और इस प्रकार वह सबसे खराब स्थिति में आ रहा है, जहां वह हर 125 MiB को हस्तांतरित एक undetectable त्रुटि इंजेक्ट कर सकता है, तो आपको बस इसे बदलना होगा, ASAP।

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

यह अच्छी तरह से ट्रोड ग्राउंड है। आप शायद एक विचार, आपत्ति या समाधान के साथ नहीं आ सकते हैं, जो कंप्यूटर विज्ञान पत्रिकाओं में मृत्यु के बारे में पहले से ही चर्चा नहीं की गई है।

SATA निश्चित रूप से पूरी तरह से विश्वसनीय नहीं है, लेकिन जब तक आप एकेडमिया या कर्नेल डेवलपमेंट टीमों में से एक में शामिल होने जा रहे हैं, आप यहां कला की स्थिति में भौतिक रूप से जोड़ने की स्थिति में नहीं होंगे। ये समस्याएँ पहले से ही ठीक हैं, जैसा कि आप पहले ही नोट कर चुके हैं: ZFS, btrfs, ReFS ... एक OS उपयोगकर्ता के रूप में, आपको बस यह विश्वास करना होगा कि OS के निर्माता आपके लिए इन समस्याओं का ध्यान रख रहे हैं, क्योंकि वे भी जानते हैं बीजान्टिन जनरलों के बारे में।

यह है वर्तमान में व्यावहारिक नहीं ZFS या Btrfs के शीर्ष पर अपने स्वैप फ़ाइल डाल करने के लिए, लेकिन अगर इसके बाद के संस्करण आपको आश्वस्त नहीं करता है, आप कम से कम यह XFS या ext4 के ऊपर डाल सकता है। यह एक समर्पित स्वैप विभाजन का उपयोग करने से बेहतर होगा।

Comments

यदि आपके पास RAID है तो आप अपने स्वैप को आदर्श रूप से RAID के शीर्ष पर चलाते हैं। अन्यथा, आप स्वैप प्रोग्राम को तब क्रैश कर देंगे जब आपका स्वैप मर जाएगा। RAID के उपयोगों में से एक डिस्क विफलता से बचने के लिए, एक नई डिस्क को गर्म-स्वैप करना और रिबूट किए बिना चालू रखना है।

— sourcejedi

Answer 2

dm-अखंडता

देखें: प्रलेखन / डिवाइस-मैपर / डीएम-अखंडता

dm-integrityसामान्य रूप से जर्नलिंग मोड में उपयोग किया जाएगा। स्वैप के मामले में, आप जर्नलिंग के बिना करने की व्यवस्था कर सकते हैं। यह प्रदर्शन ओवरहेड को काफी कम कर सकता है। मुझे यकीन नहीं है कि अशुद्ध शटडाउन के बाद त्रुटियों को पकड़ने से बचने के लिए आपको प्रत्येक बूट पर स्वैप-ओवर-अखंडता विभाजन को पुन: स्वरूपित करने की आवश्यकता होगी।

की प्रारंभिक घोषणा मेंdm-integrity , लेखक इसके बजाय "उच्च स्तर पर डेटा अखंडता संरक्षण" के लिए प्राथमिकता बताता है। स्वैप के मामले में, इससे रैम में चेकसमों के भंडारण की संभावना खुल जाएगी। हालांकि, उस विकल्प को वर्तमान स्वैप कोड में गैर-तुच्छ संशोधनों की आवश्यकता होगी, और मेमोरी उपयोग में वृद्धि होगी। (वर्तमान कोड पटरियों को कुशलतापूर्वक उपयोग करते हुए स्वैप करता है, न कि व्यक्तिगत पेज / सेक्टर)।

---

DIF / DIX?

Linux 2.6.27 (2008) में Oracle द्वारा DIX समर्थन जोड़ा गया था ।

क्या DIX का उपयोग अंत-से-अंत अखंडता प्रदान करता है?

आप अपने विक्रेता से परामर्श कर सकते हैं। मुझे नहीं पता कि आप कैसे बता सकते हैं कि वे इसके बारे में झूठ बोल रहे हैं।

OS (ऑपरेटिंग सिस्टम) और HBA के बीच उड़ान में डेटा की सुरक्षा के लिए DIX की आवश्यकता होती है ।

DIF अपने आप में HBA और स्टोरेज डिवाइस के बीच उड़ान में डेटा की सुरक्षा बढ़ाता है । (यह भी देखें: त्रुटि दर के अंतर के बारे में कुछ आंकड़ों के साथ प्रस्तुति )।

शायद ही क्योंकि गार्ड क्षेत्र में चेकसम को मानकीकृत किया जाता है , बाकी के लिए डेटा के लिए कोई सुरक्षा प्रदान किए बिना डीआईएक्स कमांड को लागू करना तकनीकी रूप से संभव है । बस एचबीए (या स्टोरेज डिवाइस) चेकसम को रीड टाइम पर रिजेक्ट कर दें। मूल DIX प्रोजेक्ट द्वारा इस आउटलुक को काफी स्पष्ट किया गया था।

• DIF / DIX हैं ओर्थोगोनल तार्किक ब्लॉक चेकसम को
  • हम अभी भी तुमसे प्यार करते हैं, btrfs!
  • लॉजिकल ब्लॉक चेकसम एरर का उपयोग दूषित डेटा का पता लगाने के लिए किया जाता है
  • READ समय पर डिटेक्शन होता है
  • ... जो महीनों बाद हो सकता है, मूल बफर खो गया है
  • मूल बफ़र गरबा किया गया था तो किसी भी अनावश्यक प्रतियां खराब हो सकती हैं
• DIF / DIX लगातार भ्रष्टाचार को रोकने के बारे में है
  • पहली बार में डिस्क पर संग्रहीत होने से खराब डेटा को रोकना
  • ... और समस्याओं के बारे में पता लगाने से पहले मूल बफर को स्मृति से मिटा दिया जाता है

- lpc08-data-Integr.pdf oss.oracle.com से

DIX के बारे में उनकी शुरुआती पोस्टिंग में OS और HBA के बीच DIX का उपयोग करने की संभावना का उल्लेख है, यहां तक ​​कि जब ड्राइव DIF का समर्थन नहीं करता है।

पूर्ण उद्यमता "उद्यम" संदर्भों में अपेक्षाकृत कम संभावना नहीं है जहां DIX वर्तमान में उपयोग किया जाता है; लोग इसे नोटिस करेंगे। इसके अलावा, डीआईएफ मौजूदा हार्डवेयर पर आधारित था जिसे 520-बाइट क्षेत्रों के साथ स्वरूपित किया जा सकता था। कथित तौर पर डीआईएफ का उपयोग करने के लिए प्रोटोकॉल की आवश्यकता है कि आप पहले ड्राइव को सुधारें, उदाहरण के लिए sg_formatकमांड देखें।

अधिक संभावना यह है कि एक क्रियान्वयन सही अंत-टू-एंड सिद्धांत का पालन नहीं करता है । एक उदाहरण देने के लिए, एक विक्रेता का उल्लेख किया गया है जो CPU चक्र को बचाने के लिए DIX के लिए एक कमजोर चेकसम विकल्प का समर्थन करता है, जिसे बाद में स्टैक में नीचे एक मजबूत चेकसम द्वारा बदल दिया जाता है। यह उपयोगी है, लेकिन यह एंड-टू-एंड सुरक्षा नहीं है।

वैकल्पिक रूप से, एक OS अपने स्वयं के चेकसम उत्पन्न कर सकता है और उन्हें एप्लीकेशन टैग स्पेस में स्टोर कर सकता है। हालांकि वर्तमान लिनक्स (v4.20) में इसके लिए कोई समर्थन नहीं है । 2014 में लिखी गई टिप्पणी से यह पता चलता है कि "बहुत कम स्टोरेज डिवाइस वास्तव में एप्लिकेशन टैग स्पेस का उपयोग करने की अनुमति देते हैं"। (मैं निश्चित नहीं हूँ कि क्या यह स्टोरेज डिवाइस, HBA या दोनों को संदर्भित करता है)।

लिनक्स के साथ काम करने वाले किस प्रकार के DIX डिवाइस उपलब्ध हैं?

डेटा और अखंडता मेटाडेटा बफ़र्स के साथ-साथ चेकसम में विकल्प को अलग करने को डेटा इंटीग्रिटी एक्सटेंशन्स [DIX] के रूप में संदर्भित किया जाता है। चूंकि ये एक्सटेंशन प्रोटोकॉल बॉडीज़ (T10, T13) के दायरे से बाहर हैं, Oracle और इसके पार्टनर इन्हें स्टोरेज नेटवर्किंग इंडस्ट्री एसोसिएशन के भीतर मानकीकृत करने की कोशिश कर रहे हैं।

- v4.20 / प्रलेखन / ब्लॉक / डेटा-अखंडता

विकिपीडिया बताता है कि NVMe 1.2.1 में DIF मानकीकृत है। SCSI HBA के लिए, यदि हम इंगित करने के लिए कोई मानक नहीं रखते हैं, तो इसे पिन करना थोड़ा मुश्किल लगता है। फिलहाल "Linux DIX" समर्थन :-) के बारे में बात करना सबसे सटीक हो सकता है। उपलब्ध उपकरण हैं:

SCSI T10 DIF / DIX [sic] पूरी तरह से Red Hat Enterprise Linux 7.4 में समर्थित है, बशर्ते कि हार्डवेयर विक्रेता ने इसे क्वालिफाई किया हो और विशेष HBA और स्टोरेज सरणी कॉन्फ़िगरेशन के लिए पूर्ण समर्थन प्रदान करता हो। DIF / DIX अन्य कॉन्फ़िगरेशन पर समर्थित नहीं है, यह बूट डिवाइस पर उपयोग के लिए समर्थित नहीं है, और यह वर्चुअलाइज्ड मेहमानों पर समर्थित नहीं है।

वर्तमान समय में, निम्नलिखित विक्रेताओं को यह सहायता प्रदान करने के लिए जाना जाता है ...

- RHEL 7.5 रिलीज़ नोट्स, अध्याय 16। संग्रहण

आरएचईएल 7.5 रिलीज नोट में उल्लिखित सभी हार्डवेयर फाइबर चैनल है।

मैं इस बाजार को नहीं जानता। ऐसा लगता है कि DIX भविष्य में सर्वरों में अधिक व्यापक रूप से उपलब्ध हो सकता है। मुझे कोई कारण नहीं पता कि यह उपभोक्ता SATA डिस्क के लिए क्यों उपलब्ध होगा - जहां तक ​​मुझे पता है कि कमांड प्रारूप के लिए कोई वास्तविक मानक भी नहीं है। मुझे यह देखने में दिलचस्पी होगी कि क्या यह NVMe पर अधिक व्यापक रूप से उपलब्ध है।

Comments

धन्यवाद! मैंने सोचा था कि मैंने देव-मैपर के लिए कुछ अखंडता "addon" के बारे में सुना है, लेकिन वास्तव में निश्चित नहीं था।

— पूज

Answer 3

स्वैप है ??? <--- यह मेरा सवाल है

स्वैप अभी भी लिनक्स में संरक्षित नहीं है (लेकिन UPD देखें)।

ठीक है, निश्चित रूप से लिनक्स पर जेडएफएस है जो स्वैप स्टोरेज होने में सक्षम है, लेकिन कुछ परिस्थितियों में अभी भी एक लॉक-अप है - इस प्रकार प्रभावी रूप से उस विकल्प को रद्द करना।

Btrfs अभी भी स्वैप फ़ाइलों को संभाल नहीं सकता है । वे लूपबैक के संभावित उपयोग का उल्लेख करते हैं, हालांकि यह खराब प्रदर्शन का उल्लेख है। एक संकेत अस्पष्ट है कि लिनक्स 5 आखिरकार (?) हो सकता है ...

चेकसम के साथ पारंपरिक स्वैप की रक्षा के लिए पैच इसे मुख्यधारा में नहीं ला सके।

तो, सब-में-सब: nope। लिनक्स में अभी भी एक अंतर है।

युपीडी। : जैसा कि @ sourcejedi बताते हैं कि डीएम-अखंडता के रूप में ऐसा एक उपकरण है। संस्करण 4.12 के बाद से लिनक्स कर्नेल ने डिवाइस-मैपर के लक्ष्य को प्राप्त कर लिया है जिसे किसी भी सामान्य ब्लॉक डिवाइस को चेकसम प्रदान करने के लिए उपयोग में लाया जा सकता है और जो स्वैप के लिए हैं वे अपवाद नहीं हैं। टूलींग को मोटे तौर पर प्रमुख डिस्ट्रोस में शामिल नहीं किया गया है और उनमें से अधिकांश को udv सब-सिस्टम में कोई समर्थन नहीं है, लेकिन अंततः इसे बदलना चाहिए। जब अतिरेक प्रदाता के साथ जोड़ा जाता है, तो एमडी उर्फ ​​लिनक्स सॉफ्टवेयर RAID के एक शीर्ष पर रखें, यह न केवल बिट रॉट का पता लगाने के लिए संभव होना चाहिए, बल्कि स्वस्थ डेटा के लिए I / O अनुरोध को फिर से रूट करने के लिए भी होना चाहिए क्योंकि dm-अखंडता का संकेत होगा कि वहाँ एक है मुद्दा और एमडी को इसे संभालना चाहिए।

Answer 4

मुझे नहीं लगता कि कोई "विहित" तरीका है, इसलिए निम्नलिखित मेरी व्यक्तिगत राय है।

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

व्यक्तिगत रूप से, मेरे पास यह तय करने का समय नहीं है कि किस सुविधा का उपयोग करना है और कौन सा नहीं, उस समय को छोड़ दें, जिसमें मुझे यह पता लगाने की आवश्यकता होगी कि इन सुविधाओं को कैसे बंद या चालू किया जाए।

इसके विपरीत, ZFS रॉक-सॉलिड और परिपक्व (IMHO) है। तो, आपके प्रश्न का उत्तर देने के लिए, मैं ZFS का उपयोग करूंगा (वैसे, यह बहुत मेमोरी का उपभोग नहीं करता है - नीचे देखें)।

लेकिन आपके लिए, btrfs सही विकल्प हो सकता है क्योंकि आप इसे पहले से ही उपयोग कर रहे हैं (यदि मैं आपको सही लगा), और ऊपर दी गई टिप्पणियों में से एक यह बताती है कि इसे स्वैप के लिए कैसे उपयोग किया जाए।

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

ZFS की मेमोरी खपत

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

हार्डवेयर त्रुटि का पता लगाने / सुधार

क्या डेटा की अखंडता के लिए SATA, PATA's, RAID या अन्य त्रुटि का पता लगाने / सुधार तंत्र पर्याप्त हैं एक विषय है जो नेट पर सभी स्थानों पर अंतहीन चर्चा और यहां तक ​​कि लौ युद्धों का कारण बनता है। सिद्धांत रूप में, एक हार्डवेयर स्टोरेज डिवाइस को रिपोर्ट (और संभवतः सही) किसी भी त्रुटि का सामना करना चाहिए और सभी स्तरों (चिपसेट, मेमोरी आदि) पर डेटा ट्रांसमिशन हार्डवेयर भी करना चाहिए।

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

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

क्या यह उचित व्यवहार है? जहां तक ​​मुझे पता है, अधिकांश हार्डवेयर RAID5 नियंत्रक और यहां तक ​​कि लिनक्स के एमडी RAID इस तरह से काम करते हैं।

मुझे btrfs की त्रुटि सुधार के बारे में नहीं पता है, लेकिन आपको अंततः डॉक्स को एक बार फिर ध्यान से पढ़ना चाहिए, विशेष रूप से यदि आप btrfs के RAID का उपयोग कर रहे हैं।

मूक सा सड़ांध

सभी लौ युद्धों और (छद्म-) वैज्ञानिक चर्चाओं के बावजूद: वास्तविकता ज्यादातर सिद्धांत से भिन्न होती है, और साइलेंट बिट रॉट निश्चित रूप से होता है, हालांकि सिद्धांत विपरीत हो सकता है (साइलेंट बॉट सड़ांध का आमतौर पर मतलब है कि हार्डवेयर स्टोरेज पर डेटा स्टोरेज डिवाइस के बिना दूषित हो जाता है। त्रुटि जब यह डेटा पढ़ा जाता है, लेकिन मैं इस परिभाषा में संचरण पथ में कहीं भी फ्लिपिंग बिट्स जोड़ूंगा)।

ऐसा होता है कि यह मेरी व्यक्तिगत राय नहीं है: कम से कम Google, अमेज़न और सर्न ने उस विषय को कवर करते हुए विस्तृत श्वेत पत्र प्रकाशित किए हैं। कागजात सार्वजनिक रूप से मुफ्त में डाउनलोड करने के लिए उपलब्ध हैं। उन्होंने कई लाखों हार्ड डिस्क और सैकड़ों हजारों सर्वर / स्टोरेज डिवाइस के साथ व्यवस्थित प्रयोग किए हैं, या तो क्योंकि उन्हें डेटा के भ्रष्टाचार की समस्या थी या क्योंकि वे जानना चाहते थे कि ऐसा होने से पहले उसे रोकने के लिए क्या करना चाहिए।

सारांश में, उनके सर्वर फ़ार्म में डेटा MTBF आँकड़ों की तुलना में काफी अधिक दर के साथ दूषित हो गया था या अन्य सिद्धांत इसकी उम्मीद करते हैं। काफी अधिक होने से मेरा मतलब है कि परिमाण के आदेश।

संचरण मार्ग में किसी भी बिंदु पर मूक बिट रॉट, यानी अंडरएक्टेड डेटा भ्रष्टाचार, एक वास्तविक जीवन की समस्या है।

डेटा जीवन भर

वॉरेन यंग सही है जब वह कहता है कि स्वैप डेटा का जीवनकाल छोटा है। लेकिन मैं निम्नलिखित विचार जोड़ना चाहूंगा: न केवल डेटा (दस्तावेजों के अर्थ में) स्वैप में मिलता है, बल्कि ओ / एस या अन्य चल रहे सॉफ़्टवेयर के कुछ हिस्सों (शायद और भी अधिक संभावना है) । यदि मेरे पास स्वैप में एक एमपी 3 है, तो मैं फ़्लिपिंग बिट के साथ रह सकता हूं। अगर मेरे उत्पादन के कुछ हिस्सों (चरम स्थिति के कारण) httpd सर्वर सॉफ़्टवेयर स्वैप में हैं, तो मैं किसी भी तरह से फ़्लिपिंग बिट के साथ नहीं रह सकता हूं, जो बाद में यदि अवांछित हो तो भ्रष्ट कोड निष्पादित करता है।

उपसंहार

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

यह कहने के बाद, कृपया ध्यान दें कि आपको पूर्ण सुरक्षा कभी नहीं मिलेगी। व्यक्तिगत रूप से, मुझे अपने डिस्क से अधिक अपनी ईसीसी रैम पर भरोसा है, और मुझे विश्वास है कि ZFS अपने एंड-टू-एंड चेकसम के साथ समस्या की संभावनाओं को परिमाण के आदेशों से कम कर देता है। मैं कभी भी ECC RAM के बिना ZFS का उपयोग करने की सलाह नहीं दूंगा।

अस्वीकरण: मैं किसी भी ZFS विक्रेता या डेवलपर से जुड़ा नहीं हूं। यह ZFS के सभी वेरिएंट (कांटे) के लिए सही है। मैं पिछले दिनों इसका प्रशंसक बन गया ...