Linux 6.2 कर्नेल में Btrfs में RAID5/6 में सुधार शामिल होंगे

RAID 6.2/5 कार्यान्वयन में "राइट होल" समस्या को ठीक करने के लिए लिनक्स 6 कर्नेल में शामिल करने के लिए Btrfs सुधार प्रस्तावित हैं। समस्या का सार इस तथ्य पर उबलता है कि यदि रिकॉर्डिंग के दौरान कोई दुर्घटना हुई, तो शुरू में यह समझना असंभव है कि किस RAID डिवाइस पर कौन सा ब्लॉक सही तरीके से लिखा गया था, और जिसमें रिकॉर्डिंग पूरी नहीं हुई थी। यदि आप इस स्थिति में एक RAID को फिर से बनाने का प्रयास करते हैं, तो अंडरराइट किए गए ब्लॉक के अनुरूप ब्लॉक दूषित हो सकते हैं क्योंकि RAID ब्लॉक की स्थिति सिंक से बाहर है। यह समस्या किसी भी RAID1/5/6 सरणियों में होती है जहाँ इस प्रभाव से निपटने के लिए विशेष उपाय नहीं किए जाते हैं।

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

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

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

इसके अतिरिक्त, हम डेवलपर्स से RAID5 / 6 के उपयोग पर सिफारिशों को नोट कर सकते हैं, जिसका सार यह है कि Btrfs में मेटाडेटा और डेटा संग्रहीत करने के लिए प्रोफ़ाइल भिन्न हो सकती है। इस स्थिति में, आप मेटाडेटा के लिए RAID1 (मिरर) या यहां तक ​​कि RAID1C3 (3 प्रतियां) प्रोफ़ाइल और डेटा के लिए RAID5 या RAID6 का उपयोग कर सकते हैं। यह मेटाडेटा की विश्वसनीय सुरक्षा सुनिश्चित करता है और एक ओर "राइट होल" की अनुपस्थिति, और दूसरी ओर RAID5/6 के लिए विशिष्ट स्थान का अधिक कुशल उपयोग सुनिश्चित करता है। यह मेटाडेटा में भ्रष्टाचार से बचाता है, और डेटा भ्रष्टाचार को ठीक किया जा सकता है।

यह भी ध्यान दिया जा सकता है कि 6.2 कर्नेल में Btrfs में SSDs के लिए, "त्याग" ऑपरेशन का अतुल्यकालिक निष्पादन (मुक्त ब्लॉकों को चिह्नित करना जो अब भौतिक रूप से संग्रहीत नहीं किया जा सकता है) को डिफ़ॉल्ट रूप से सक्रिय किया जाएगा। इस मोड का लाभ एक कतार में "छोड़ें" संचालन के कुशल समूहीकरण और पृष्ठभूमि हैंडलर द्वारा कतार की आगे की प्रक्रिया के कारण उच्च प्रदर्शन है, जिसके कारण सामान्य FS संचालन धीमा नहीं होता है, जैसा कि तुल्यकालिक " त्यागें" क्योंकि ब्लॉक मुक्त हो जाते हैं, और SSD बेहतर निर्णय ले सकता है। दूसरी ओर, आपको अब fstrim जैसी उपयोगिताओं का उपयोग करने की आवश्यकता नहीं होगी, क्योंकि सभी उपलब्ध ब्लॉक अतिरिक्त स्कैनिंग की आवश्यकता के बिना और संचालन को धीमा किए बिना FS में साफ़ कर दिए जाएंगे।

स्रोत: opennet.ru