Linux 6.2 कर्नल Btrfs मध्ये RAID5/6 मध्ये सुधारणा समाविष्ट करेल

Btrfs सुधारणा RAID 6.2/5 अंमलबजावणीमध्ये राइट होल समस्येचे निराकरण करण्यासाठी Linux 6 कर्नलमध्ये समावेश करण्यासाठी प्रस्तावित केल्या आहेत. समस्येचे सार या वस्तुस्थितीवर येते की रेकॉर्डिंग दरम्यान क्रॅश झाल्यास, कोणत्या ब्लॉकवर RAID डिव्हाइस योग्यरित्या लिहिले गेले होते आणि ज्यामध्ये रेकॉर्डिंग पूर्ण झाले नाही हे समजणे सुरुवातीला अशक्य आहे. या परिस्थितीत तुम्ही RAID पुनर्संचयित करण्याचा प्रयत्न केल्यास, अंडरराइट केलेल्या ब्लॉक्सशी संबंधित ब्लॉक्स नष्ट होऊ शकतात कारण RAID ब्लॉक्सची स्थिती समक्रमित झाली आहे. ही समस्या कोणत्याही RAID1/5/6 अॅरेमध्ये उद्भवते जेथे या प्रभावाचा सामना करण्यासाठी विशेष उपाय केले गेले नाहीत.

RAID अंमलबजावणीमध्ये, btrfs मधील RAID1 प्रमाणे, ही समस्या दोन्ही प्रतींमध्ये चेकसम वापरून सोडवली जाते; जर काही जुळत नसेल, तर डेटा फक्त दुसऱ्या प्रतीतून पुनर्संचयित केला जातो. जर काही डिव्हाइस पूर्ण अपयशी होण्याऐवजी चुकीचा डेटा पाठवण्यास सुरुवात करत असेल तर हा दृष्टीकोन देखील कार्य करतो.

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

btrfs च्या बाबतीत, जर तयार केले जाणारे रेकॉर्ड स्ट्राइपपेक्षा लहान असेल तर ही समस्या सर्वात संबंधित आहे. या प्रकरणात, फाइल सिस्टमने रीड-मॉडिफाई-राइट ऑपरेशन (रीड-मॉडिफाई-राइट, RMW) करणे आवश्यक आहे. यात अपूर्ण लेखनासह ब्लॉक आढळल्यास, 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