Reiser4 डेवलपर Eduard Shishkin के साथ साक्षात्कार

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



- कर्नेल में reiser4 के प्रचार के बारे में क्या?



मैं अब इसके लिए तकनीकी बाधाएँ नहीं देखता: प्रसिद्ध "समावेश के लिए सूची" से सभी समस्याओं का समाधान किया गया है। यह केवल VFS के साथ संबंध स्पष्ट करने के लिए बना हुआ है, और प्रकाशन के लिए संबंधित लेख अभी तक तैयार नहीं है।



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



लोकप्रिय भविष्यवाणियों के बारे में कि "reiser4 कर्नेल में शामिल नहीं होगा और यह मर जाएगा," मैं यह कहना चाहता हूं कि मैं मुख्य लिनक्स कर्नल शाखा में प्रोजेक्ट को शामिल करके "जीवन के लिए टिकट" के साथ जुनून को नहीं समझता हूं। Reiser4 डेटा भंडारण के क्षेत्र में 18 साल के शोध का परिणाम है, एक विशिष्ट ऑपरेटिंग सिस्टम से बंधा हुआ नहीं है। नतीजा, जिस पर कई वैज्ञानिकों ने काम किया। वे इसे लिनक्स में चालू नहीं करेंगे - वे इसे दूसरे ओएस में चालू करेंगे, जहां हमारे विचार दिलचस्प लगेंगे। लिनक्स पर, प्रकाश ने पच्चर को रूपांतरित नहीं किया ...



- क्या यह अपनी छवि सुधारने के लिए reiser4 के बारे में एक विज्ञापन अभियान की तरह कुछ करने के लिए समझ में आता है?



सबसे अच्छा विज्ञापन अभियान लोगों को यह समझाने के लिए है कि यह कैसे काम करता है। हर कोई उसके कोड को देख रहा है, और कोई भी कुछ भी नहीं समझता है। यहां आपके पास ओपन सोर्स है। यह कैसे समझा जाए? केवल प्रतिष्ठित प्रकाशनों में प्रकाशित लेख। और, ज़ाहिर है, किसी भी विकिपीडिया की कोई बात नहीं हो सकती है। पुनर्जागरण कलाकारों के कार्यों को कवर करने के लिए विकिपीडिया अच्छा है। और यहां आपकी परियोजना का पृष्ठ प्रतियोगियों के लिए एक शौचालय बनने का जोखिम रखता है।



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



- आप व्यक्तिगत रूप से बीएफएस ( सीपीयू-शेड्यूलर ), बीएफक्यू ( आई / ओ-शेड्यूलर ) के बारे में क्या सोचते हैं?



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



- आपको क्या लगता है, क्यों कच्चे और अविश्वसनीय एफएस ext4 को लगभग तुरंत कर्नेल में स्वीकार किया गया था?



खैर, यह डी फैक्टो स्टैंडर्ड लिनक्स एक्सटे फाइल सिस्टम का तार्किक विस्तार है। यह आश्चर्य की बात होगी अगर उनके यहाँ लाल बत्ती होती।



- कोर में एफएस की उस भारी मात्रा के बारे में आप कैसा महसूस करते हैं? क्या यह उचित है?



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



- इस साल और अगले साल आप किन प्रदर्शनियों और मंचों पर बोलने जा रहे हैं?



उन्होंने अभी तक किसी को आमंत्रित नहीं किया है। मैं खुद कभी पहल नहीं दिखाता।



- क्या आप reiser4 विकसित करने के लिए प्रेरित करता है? आखिरकार, कई अन्य एफएस हैं।



कोई मजबूत प्रेरणा नहीं है। सबसे पहले मैं अंत में पारदर्शी संपीड़न को पूरा करना चाहता था। फिर, 2007 में उसकी घोषणा के बाद, मैं कुछ भी नहीं करने के कारण Reiser4 के साथ व्यस्त था: मुझे लंबे समय तक नौकरी नहीं मिली। अब मैं डेटा संग्रहण विज्ञान के कुछ पहलुओं पर दिलचस्पी लेना जारी रखता हूं, जिस पर Reiser4 आधारित है। बाकी स्थानीय एफएस मेरे लिए दिलचस्प नहीं हैं।



- क्या आप हंस के साथ संवाद करने के लिए अनौपचारिक रूप से "पर्दे के पीछे" जारी रखते हैं? क्या वह विकास में कोई हिस्सा लेता है?



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



- आपका मुख्य काम क्या है?



मैं Red Hat फाइल सिस्टम डिवीजन में काम करता हूं।



- reiser4 करने के लिए पर्याप्त समय है?



अपेक्षाकृत बोलना, यह पर्याप्त है, लेकिन केवल समर्थन के लिए: मैं आमतौर पर VFS, ब्लॉक लेयर में किए गए सभी परिवर्तनों के साथ अद्यतित हूं। उनके लिए reiser4 को अनुकूलित करने के लिए, एक सप्ताहांत आमतौर पर पर्याप्त होता है। डेवलपमेंट का मतलब है नए प्लगइन्स की प्रोग्रामिंग करना। इसका मतलब है कि पूर्ण रोजगार, कम नहीं। यानी यह केवल वेतन के लिए संभव है, और अभी तक कोई भी इसके लिए भुगतान करने वाला नहीं है।



- समर्थन में कितने लोग शामिल हैं? क्या आपके पास एक उत्तराधिकारी है अगर आपको अचानक reiser4 के लिए समर्थन छोड़ना पड़ा?



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



- क्या मालिकाना OS में उपयोग के लिए reiser4 कोड को लाइसेंस देना संभव है?



मैं इस तरह के सवालों से दूर हूं। आप हंस से पूछ सकते हैं कि क्या यह बहुत दिलचस्प है।



- क्या रीसेल 4 आरएचईएल की अगली रिलीज में से एक में डिफ़ॉल्ट एफएस बन सकता है?



यह एक प्रश्न है, बल्कि, मेरे प्रबंधक के लिए: मैं Red Hat की योजनाओं पर चर्चा नहीं कर सकता। मैं केवल इतना कह सकता हूं कि अभी तक मैंने किसी को कुछ नहीं दिया है, लेकिन किसी ने मुझसे कुछ नहीं पूछा।



- क्या आप FreeBSD को reiser4 पोर्ट करने की योजना बना रहे हैं? शायद आपको FUSE का उपयोग करके एक पोर्ट बनाने पर विचार करना चाहिए? कोर में बदलावों को स्वीकार करने की नीति के बारे में आप क्या सोचते हैं?



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



- क्या "नुकसान" एक व्यक्ति को रोजमर्रा के काम में reiser4 की कोशिश करना चाहते हो सकता है? आप इसकी स्थिरता को कैसे आंकते हैं?



सामान्य टिप्पणी: पिछले चार वर्षों में, मैं ठीक से काम करने वाले हार्डवेयर के साथ reiser4 विभाजन पर डेटा खोने वाले किसी भी व्यक्ति को याद नहीं करता। मुझे कई लोगों द्वारा fsck के काम के बारे में शिकायत करने के लिए संपर्क किया गया था। अंत में, वे सभी अपने डेटा और काम कर रहे fsck मिल गए।



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



- क्या आप डीफ़्रैग्मेन्टेशन के लिए एक उपयोगिता बनाने की योजना बनाते हैं? उदाहरण के लिए, torrents के साथ एक खंड पर reiser4 का उपयोग करते समय, यह 700-मेगाबाइट फ़ाइल प्रति 11000 से अधिक टुकड़े निकला, और कोई भी नकल इस आंकड़े को कम से कम कई सौ तक लाने में सक्षम नहीं थी। इसी समय, उत्पादकता के लिए मूर्त नकारात्मक परिणाम थे।



हां, यह योजनाबद्ध है। ऐसी उपयोगिता होना महत्वपूर्ण है। Reiser4 Transaction Manager लॉगिंग और कॉपी-ऑन-राइट तकनीकों के मिश्रण का उपयोग करता है। अपने आप में पहले से ही विखंडन का मतलब है। इससे छुटकारा पाने के लिए, एक भी प्रति पर्याप्त नहीं हो सकती है: आखिरकार, मुफ्त डिस्क स्थान भी खंडित हो सकता है। सामान्य तौर पर, डीफ़्रैग्मेन्टेशन उपयोगिता पेड़ के कई पास में स्थिति में काफी सुधार करेगी। एक बाहरी विखंडन से लड़ सकता है - यह एफएस के लिए एक वाक्य नहीं है।



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



- reiser4 का उपयोग करते समय विशिष्ट हार्डवेयर के साथ कोई समस्या है?



मैंने ऐसा नहीं सुना है। यह एक सर्वज्ञ की तरह लगता है।



- क्या grub2 के लिए reiser4 समर्थन reiser4 डेवलपर्स द्वारा खुद को लागू किया जाएगा?



मुझे उम्मीद है कि ऐसा ही होगा यह श्रमसाध्य कार्य है, लेकिन यह सफल होने की गारंटी है। ग्रब-0.97 के लिए एक पैच है। इसके आधार पर, चमत्कारिक रूप से, आप grub2 के लिए reiser4 समर्थन को व्यवस्थित कर सकते हैं। मौजूदा पैच का नुकसान यह है कि डाउनलोड मंच 1_5 के माध्यम से नहीं जा सकता है इस कारण से कि संबंधित बाइनरी बहुत बड़ी है और इसके लिए आवंटित 62 क्षेत्रों में फिट नहीं है। और चरण 1_5 के माध्यम से बूट करने में असमर्थता का मतलब है कि हर बार एक डीफ़्रैग्मेंटर आपके विभाजन पर काम करता है, आपको ग्रब को पुनर्स्थापित करने की आवश्यकता है। Grub2 के लिए reiser4 समर्थन में, सब कुछ अच्छी तरह से किया जाना चाहिए। मल्टी-डिवाइसेस से मॉड्यूल लोड करने वाले ट्राउट मेरे 62 सेक्टर में फिट होते हैं। Reiser4 वहाँ क्यों फिट नहीं है?



- क्या भविष्य में यूजरस्पेस में प्लग-इन को हटाना संभव है? क्या कोई योजनाएं हैं? क्या आप एक ऐसा इन्फ्रास्ट्रक्चर बनाने की योजना बना रहे हैं जो कर्नेल स्पेस और यूजर स्पेस दोनों में प्लग-इन लोड कर सके?



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



- क्या यह परीक्षण के एक सेट को लिखने के लिए लायक है जो विभिन्न तरीकों से ताकत के लिए एफएस का परीक्षण करेगा और समस्याएं दिखाएगा? उदाहरण के लिए, यह पर्ल स्क्रिप्ट्स का एक सेट हो सकता है जो आक्रामक समानांतर राइट्स, रीड और डिलीट का संचालन करेगा, रीड डेटा को लिखे हुए लोगों के साथ पत्राचार दिखाएगा, और समस्याओं के लिए फाइल सिस्टम की संरचना की भी जांच करेगा।



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



- zfs / btrfs ने reiser4 को कैसे प्रभावित किया?



कोई रास्ता नहीं। Reiser4 आंशिक रूप से xfs ( "विलंबित आवंटन" तकनीक ) के विकास से प्रभावित था। मूल रूप से, उन्होंने अपने स्वयं के विकास का उपयोग किया।



- क्या आप सीधे btrfs के विकास में शामिल हैं?



आंशिक रूप से नियोक्ता की ओर से। मैंने grub-0.97 में btrfs का समर्थन किया ( हमारे वितरण grub2 के साथ काम नहीं करता है )। मुझे नहीं पता कि और क्या सौंपा जाएगा। यह संभव है कि ट्रेंडी फीचर "डेटा डिडुप्लीकेशन" हो।



- मेसन के साथ हालिया सनसनीखेज पत्राचार के बाद btrfs के साथ वर्तमान मामलों पर आपकी क्या राय है?



क्यों "सनसनीखेज"? सामान्य काम का माहौल। मुझे एंटरप्राइज़ सिस्टम में इसकी प्रयोज्यता के लिए btrfs की जांच करने का काम सौंपा गया था, इसलिए मुझे उन मॉडलों पर मजबूत आंतरिक विखंडन मिला जहां बाकी एफएस त्रुटिपूर्ण रूप से काम करते हैं। तदनुसार, मुझे यह पता लगाना शुरू हुआ कि क्या यह एक गलती है, या एक "सुविधा" है। सच है, आधा साल पहले ही बीत चुका है, और मैंने अभी भी btrfs एल्गोरिदम के बारे में कुछ भी समझदार नहीं सुना है। क्या राय हो सकती है? मुझे बस एहसास हुआ कि वे reiserfs फाइल सिस्टम की टेल पैकिंग सुविधा चाहते हैं, पूरी तरह से यह नहीं समझ रहे हैं कि बाद के काम के एल्गोरिदम और डेटा संरचनाएं कैसे हैं। मैं केवल यह कह सकता हूं कि बी-ट्रीज़ में "टेल पैकिंग" की अवधारणा किसी भी अर्थ से पूरी तरह से रहित है। और, इसके अलावा, ऐसे पेड़ों में चर आकार की वस्तुओं को रखने का प्रयास असीमित आंतरिक विखंडन की ओर जाता है। और Reiserfs बी-पेड़ों और उनके प्रसिद्ध संशोधनों का उपयोग नहीं करते हैं । वे पूरी तरह से अलग एल्गोरिदम ( रूसी वैज्ञानिकों का एक आविष्कार, वैसे ) का उपयोग करते हैं - उनके साथ 90 के दशक की शुरुआत में नेमेस का इतिहास शुरू हुआ। और उन्हें टॉप-डाउन संतुलन के लिए संशोधित करना, जैसा कि btrfs डिजाइन द्वारा आवश्यक है, क्लासिक बी-पेड़ों के विपरीत पूरी तरह से तुच्छ कार्य नहीं है।



बहुत बार मैंने सुना है कि btrfs के अनुरक्षक क्रिस मेसन, नेम्सिस में एक समय में काम किया था, क्योंकि डंकन मैकलियोड ने वहां से सभी सकारात्मक अनुभव उधार लिए थे। कुछ समय के लिए, मैं केवल विपरीत देखता हूं। किसी कारण से, उन्होंने चाबियाँ पर सहेजा ( btrfs में कुंजी 136 बिट्स है, reiser4 - 192 बिट्स में ), लेकिन वह असफल संतुलन द्वारा उपयोगकर्ताओं के डिस्क स्थान ( और RAM ) की टेराबाइट्स करता है। अतिरिक्त मुख्य फ़ील्ड डेटा और मेटाडेटा को अलग-अलग तरीकों से समूहित करने की क्षमता है। और क्या, यह सब जरूरी नहीं है ??? और ऊपर से नीचे संतुलन, मेरी राय में, एक पूर्ण समझौता है: संतुलन का निचोड़ चरण, साथ ही साथ डेटा संपीड़न और एन्क्रिप्शन, "विलंबित आवंटन" तकनीक की तरह स्थगित नहीं किया जा सकता है। और फिर, मुझे ऐसा लगता है कि ये लोग ऐसे पेड़ पर एक सभ्य लॉकिंग योजना को व्यवस्थित करने में असमर्थता के कारण स्केलेबिलिटी के साथ समस्याओं में चलेंगे। मैं केवल यह कह सकता हूं कि बड़ी संख्या में प्रक्रियाओं के बीच "वुडवर्क" को वितरित करना अधिक लाभदायक है, और उनमें से कुछ को ( नीचे से ऊपर की ओर ) जाने दें, और ऐसा नहीं है कि वे सभी एक आम जड़ के माध्यम से ऊपर से इस पेड़ में टूट जाते हैं।



सामान्य तौर पर, मुझे पता नहीं है ... मैं, ज़ाहिर है, मेरी मदद कर सकता है, लेकिन यह मामला है: यदि परियोजना बुरे विचारों पर आधारित है, तो कैंडी को इससे बाहर करना मुश्किल है। वैसे, नेम्स का पूरा इतिहास शैक्षणिक संस्थानों ( मॉस्को स्टेट यूनिवर्सिटी, इंस्टीट्यूट ऑफ सॉफ्टवेयर सिस्टम ऑफ द रशियन एकेडमी ऑफ साइंसेज ऑफ पेरेस्लाव-ज़ाल्स्की) के साथ निरंतर संपर्क है। XFS भी सिलिकॉन ग्राफिक्स में एक पूरा स्कूल है। और Btrfs क्या है की कहानी है? निम्न-स्तरीय कार्यशालाओं के जोड़े? और उन घटनाओं का नाम क्या है जिन पर गैर-मौजूद सुविधाओं की घोषणा की गई है? मैं लंबे समय से चमत्कार में विश्वास करना बंद कर दिया है ...



- आप एफएस के भविष्य को कैसे देखते हैं? उनकी क्या कार्यक्षमता होगी?



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



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



मैं उंगलियों पर यह समझाने की कोशिश करूँगा कि यह सब कैसे काम करता है। मान लीजिए कि आप btrfs ( स्नैपशॉट, आदि ) की कार्यक्षमता को लागू करना चाहते हैं। जैसा कि आप जानते हैं, यह एफएस ट्रांजेक्शनल कॉपी-ऑन-राइट मॉडल का उपयोग करता है, जो पेड़ को ऊपर से नीचे तक संतुलित करने के आधार पर कार्यान्वित किया जाता है। यह इसका मुख्य अंतर है जो वर्तमान में Reiser4 प्रदान करता है।इसलिए, हमें एक नया "प्लग-इन" प्लग-इन "TMGR" इंटरफ़ेस ( लेन-देन प्रबंधक ) बनाना होगा, साथ ही एक रूट परिवार ( "इतिहास" ) के साथ एक भंडारण पेड़ के लिए "TREE" इंटरफ़ेस का नया "मल्टी-रूट-ट्री" प्लग-इन और ऊपर से संतुलित होना चाहिए। नीचे। इस मामले में, बाद वाले को अपनी स्वयं की लॉकिंग योजना से लैस होना चाहिए। टीएमजीआर के रूप में, यह वस्तुओं के प्रबंधन के लिए एक सार वर्ग है, जिसे अगले लेख में कण कहा जाता है ( ट्रांसक्रैश आदिम के लिए एक अवधारणा दोहरी, लेख यहां है )।



यदि आप विभिन्न फाइल सिस्टम के लेनदेन प्रबंधकों को करीब से देखते हैं ( वर्तमान में ऐसे प्रबंधक तीन प्रकार के हैं), फिर उनकी कुछ सामान्य विशेषताओं को नोटिस करना आसान है। अर्थात्, TMGR इंटरफ़ेस में, निम्नलिखित मुख्य विधियों के एक सेट को प्रतिष्ठित किया जा सकता है:

• enter_context ();
• try_capture ();
• exit_context ()।

वास्तविक फ़ाइल सिस्टम से प्रक्रिया के प्रवेश और निकास के दौरान पहले और आखिरी को क्रमशः कहा जाता है। दूसरा उन सभी स्थानों पर है जहाँ डेटा ( पृष्ठ या बफ़र्स ) संशोधित हैं । अब reiser4 एक एकल TMGR प्लगइन चलाता है, इसे "jcow" कहते हैं ( इतिहास को सहेजे बिना पत्रिकाओं और कॉपी-ऑन-राइट तकनीक का सहजीवन ), विधि -> try_capture () जिनमें से एक ब्लॉक को तथाकथित में जोड़ता है "एटम" ( reiser4 में "कणों" के लिए विशेष नाम )। और हमारे नए बने प्लगइन "गाय" में यह विधि स्टोरेज ट्री की नई जड़ ( btrfs कोड में, संबंधित फ़ंक्शन को btrfs_cow_block ) कहा जाएगा ।



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



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



कुल मिलाकर, हमें btrfs की कार्यक्षमता प्राप्त करने के लिए केवल दो नए प्लगइन्स की आवश्यकता है। और वास्तव में: हमें कुछ और क्यों चाहिए? FILE इंटरफ़ेस प्लग इन TREE इंटरफ़ेस के तरीकों के अनुसार पेड़ से आइटम का चयन करता है और यह जानने की आवश्यकता नहीं है कि किसी विशेष पेड़ को कैसे संतुलित किया जाता है। अन्य इंटरफेस ( NODE, ITEM, आदि) के लिए प्लगइन्स) यह भी मामला है: हमें स्नैपशॉट के आयोजन के लिए पेड़ के नोड्स के प्रारूप को बदलने की आवश्यकता क्यों है? बस, हमारे "मल्टी-रूट" पेड़ में अलग-अलग आंतरिक नोड्स होंगे जो एक ही ब्लॉकों को संदर्भित करते हैं।



मैं यह दावा नहीं करता कि नए TREE और TMGR प्लग-इन का प्रोग्रामिंग करना आलसी लोगों के लिए एक काम है, लेकिन मेरा विश्वास करो, यह फ़ाइल सिस्टम और जटिल fsck उपयोगिता ( जो कि reiser4 के लिए मॉड्यूलर भी है , सबसे दिलचस्प बिंदु के लिए पुन: बनाने से बहुत आसान है) यहाँ यह है कि अन्य इंटरफेस के मौजूदा प्लग-इन को नए परिवार के सदस्यों के साथ काम करने के लिए पढ़ाने की आवश्यकता नहीं है, जिसका अर्थ है कि कोड लिखने और डिबग करने की आवश्यकता नहीं है, जिसका प्रतिशत 100% होगा (एक सफल संगठित इंटरफ़ेस योजना के साथ, आप सफलतापूर्वक एक से अधिक कार्यक्षमता को लागू करते हैं )।



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



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



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



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



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



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