Reiser4 FS के डेवलपर एडुआर्ड शिश्किन के साथ दूसरा साक्षात्कार

Reiser4 फ़ाइल सिस्टम के डेवलपर एडुआर्ड शिश्किन के साथ दूसरा साक्षात्कार प्रकाशित किया गया है।

आरंभ करने के लिए, कृपया पाठकों को याद दिलाएँ कि आप कहाँ और किसके लिए काम करते हैं।

मैं हुआवेई टेक्नोलॉजीज, जर्मन रिसर्च सेंटर में प्रिंसिपल स्टोरेज आर्किटेक्ट के रूप में काम करता हूं। वर्चुअलाइजेशन विभाग में मैं डेटा भंडारण के विभिन्न पहलुओं से निपटता हूं। मेरी गतिविधियाँ किसी विशिष्ट ऑपरेटिंग सिस्टम से संबंधित नहीं हैं।

क्या आप वर्तमान में मुख्य कर्नेल शाखा के लिए प्रतिबद्ध हैं?

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

मुझे याद है पिछली बार, दस साल पहले, आप कर्नेल विकास शैली के काफी आलोचक थे। आपके (या शायद कॉर्पोरेट) दृष्टिकोण से, क्या कुछ बदला है, क्या समुदाय अधिक प्रतिक्रियाशील हो गया है या नहीं? यदि नहीं, तो आपके अनुसार किसे दोषी ठहराया जाए?

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

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

आप Btrfs विकास में प्रगति का आकलन कैसे करते हैं? क्या इस एफएस से बचपन की बीमारियों से छुटकारा मिल गया? आप इसे अपने लिए कैसे रखते हैं - एफएस के रूप में "घर के लिए" या कॉर्पोरेट उपयोग के लिए भी?

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

यह इस तरह दिखता है (लिनक्स कर्नेल 5.12 के लिए परीक्षण किया गया)। एक ताज़ा स्थापित सिस्टम पर एक स्क्रिप्ट लॉन्च की जाती है, जो एक लूप में होम डायरेक्टरी में कुछ नामों के साथ फ़ाइलें बनाता है, कुछ ऑफसेट पर उनमें डेटा लिखता है, और फिर इन फ़ाइलों को हटा देता है। इस स्क्रिप्ट को चलाने के एक मिनट बाद, कुछ भी असामान्य नहीं होता है। पांच मिनट के बाद, विभाजन पर कब्जे वाली जगह का हिस्सा थोड़ा बढ़ जाता है। दो से तीन घंटों के बाद यह 50% (15% के प्रारंभिक मूल्य के साथ) तक पहुंच जाता है। और पांच या छह घंटे के काम के बाद, स्क्रिप्ट "विभाजन पर कोई खाली जगह नहीं है" त्रुटि के साथ क्रैश हो जाती है। इसके बाद, आप अपने पार्टीशन में एक 4K फ़ाइल भी नहीं लिख पाएंगे।

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

इसके अलावा, यह सब पहले से ही मूल Btrfs कॉन्फ़िगरेशन (बिना किसी स्नैपशॉट, सबवॉल्यूम आदि के) पर होता है, और इससे कोई फर्क नहीं पड़ता कि आप फ़ाइल बॉडी को उस FS में कैसे संग्रहीत करने का निर्णय लेते हैं (पेड़ में "टुकड़े" के रूप में, या विस्तार के रूप में) बिना स्वरूपित ब्लॉकों का) - अंतिम परिणाम वही होगा।

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

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

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

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

मेलिंग सूचियों को देखते हुए, मुझे अक्सर यह कथन मिलता है कि ड्राइव के सस्ते होने के कारण डिस्क स्थान को प्रभावी ढंग से प्रबंधित करना अब प्रासंगिक नहीं है। यह पूरी तरह बकवास है. एक प्रभावी डिस्क स्थान प्रबंधक के बिना, ओएस असुरक्षित और अनुपयोगी हो जाएगा। आपकी मशीन पर डिस्क की क्षमता चाहे जो भी हो।

मैं आरएचईएल में बीटीआरएफएस समर्थन बंद करने पर टिप्पणी मांगना चाहता हूं।

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

आगे। रेड हैट के ग्राहकों में जाने-माने बड़े बैंक और एक्सचेंज शामिल हैं। कल्पना करें कि यदि Btrfs में उल्लिखित भेद्यता के आधार पर वे DoS हमलों के अधीन होते तो क्या होता। आपके अनुसार इसके लिए कौन जिम्मेदार है? जो लोग जीपीएल लाइसेंस की पंक्ति पर अपनी उंगली उठाने वाले हैं, जहां लिखा है कि लेखक किसी भी चीज़ के लिए ज़िम्मेदार नहीं है, मैं तुरंत कहूंगा: "इसे छुपाएं!" रेड हैट जवाब देगा, और इस तरह से कि यह पर्याप्त नहीं लगेगा! लेकिन मुझे पता है कि रेड हैट को इस तरह की समस्या का सामना नहीं करना पड़ रहा है, क्यूए इंजीनियरों की उनकी विशेष रूप से मजबूत टीम को देखते हुए, जिनके साथ मुझे अपने समय में करीब से काम करने का अवसर मिला था।

कुछ कंपनियाँ अपने उद्यम उत्पादों में Btrfs का समर्थन क्यों जारी रखती हैं?

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

इसलिए, फेसबुक द्वारा अपने सर्वर पर Btrfs तैनात करने की अफवाह के बाद मैं किसी निष्कर्ष पर नहीं पहुंचूंगा। इसके अलावा, मैं उपरोक्त कारणों से उन सर्वरों के पते को सावधानीपूर्वक गुप्त रखने की अनुशंसा करूंगा।

हाल ही में XFS कोड को साफ करने में इतना प्रयास क्यों किया गया है? आख़िरकार, प्रारंभ में यह एक तृतीय-पक्ष फ़ाइल सिस्टम है, और ext4 लंबे समय से स्थिर है और इसमें पिछले समान रूप से स्थिर संस्करणों से निरंतरता है। Red Hat की XFS में क्या रुचि है? क्या उद्देश्य में समान दो फ़ाइल सिस्टम - ext4 और XFS को सक्रिय रूप से विकसित करना उचित है?

मुझे याद नहीं कि किस चीज़ ने इसे प्रेरित किया। यह बहुत संभव है कि पहल Red Hat ग्राहकों की ओर से हुई हो। मुझे याद है कि इस तरह का शोध किया गया था: अपस्ट्रीम से कुछ फ़ाइल सिस्टम पर, नई पीढ़ी के हाई-एंड ड्राइव पर बड़ी संख्या में ऑब्जेक्ट बनाए गए थे। परिणामों के अनुसार, XFS ने ext4 से बेहतर व्यवहार किया। इसलिए उन्होंने इसे सबसे आशाजनक के रूप में प्रचारित करना शुरू कर दिया। किसी भी स्थिति में, मैं यहां किसी भी सनसनीखेज चीज़ की तलाश नहीं करूंगा।

मेरे लिए, यह ऐसा है जैसे उन्होंने एक सूए को साबुन से बदल दिया हो। Ext4 और XFS को विकसित करने का कोई मतलब नहीं है। दोनों समानांतर में और उनमें से चुनने के लिए कोई भी। इससे कुछ भी अच्छा नहीं होगा. हालाँकि, प्रकृति में अक्सर ऐसी स्थितियाँ आती हैं जब विकास की बहुत संभावना होती है, लेकिन बढ़ने की कोई गुंजाइश नहीं होती है। इस मामले में, विभिन्न विचित्र रूप से बदसूरत नए विकास उत्पन्न होते हैं, जिस पर हर कोई उंगली उठाता है ("ओह, देखो, तुम इस जीवन में क्या नहीं देखोगे!")।

क्या आपको लगता है कि परत उल्लंघन का मुद्दा ext4, F2FS (Btrfs में RAID का उल्लेख नहीं करने) में एन्क्रिप्शन फ़ंक्शन के आगमन के साथ (नकारात्मक अर्थ में) सुलझा लिया गया है?

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

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

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

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

Reiser4 पर "नीचे से" स्तरों का उल्लंघन करने का आरोप लगाया गया था। इस तथ्य के आधार पर कि फ़ाइल सिस्टम अन्य सभी की तरह अखंड नहीं है, बल्कि मॉड्यूलर है, एक निराधार धारणा बनाई गई थी कि यह वही करता है जो ऊपर के स्तर (वीएफएस) को करना चाहिए।

क्या ReiserFS v3.6 और, उदाहरण के लिए, JFS की मृत्यु के बारे में बात करना संभव है? हाल ही में उन पर मूल रूप से लगभग कोई ध्यान नहीं दिया गया है। क्या वे अप्रचलित हैं?

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

क्या आप एफएस टक्स3 और हैमर/हैमर2 (ड्रैगनफ्लाई बीएसडी के लिए एफएस) के विकास के बारे में जानते हैं?

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

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

आप CephFS/GlusterFS/आदि जैसे नेटवर्क क्लस्टर FS की बढ़ती मांग का आकलन कैसे करते हैं? क्या इस मांग का मतलब नेटवर्क एफएस के प्रति डेवलपर्स की प्राथमिकताओं में बदलाव और स्थानीय एफएस पर अपर्याप्त ध्यान है?

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

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

उपयोगकर्ता स्थान के बजाय कर्नेल स्थान में नेटवर्क फ़ाइल सिस्टम को लागू करना सैद्धांतिक रूप से कितना उचित है?

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

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

यदि ऐसे कई स्विच हैं, तो स्टोरेज थ्रूपुट (I/O प्रदर्शन) कम हो जाएगा। यदि आपका बैकएंड स्टोरेज धीमी डिस्क से बना है, तो आपको कोई महत्वपूर्ण गिरावट नज़र नहीं आएगी। लेकिन यदि आपके पास तेज़ डिस्क (एसएसडी, एनवीआरएएम, आदि) हैं, तो संदर्भ स्विचिंग पहले से ही एक "अड़चन" बन जाती है और, संदर्भ स्विचिंग पर बचत करके, प्रदर्शन में काफी वृद्धि की जा सकती है। पैसे बचाने का मानक तरीका मॉड्यूल को कर्नेल स्पेस में ले जाना है। उदाहरण के लिए, हमने पाया कि 9p सर्वर को QEMU से होस्ट मशीन पर कर्नेल में ले जाने से VirtFS प्रदर्शन में तीन गुना वृद्धि होती है।

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

स्थानीय एफएस नेटवर्क से क्या अवधारणाएँ उधार ले सकते हैं और इसके विपरीत?

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

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

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

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

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

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

ध्यान दें कि फ़ाइल सिस्टम पर अपना स्वयं का LVM बनाने के बाद स्थिति बहुत बेहतर नहीं होती है। इसके अलावा, ऐसा करके आप वास्तव में भविष्य में इसमें कभी सुधार लाने की संभावना को ख़त्म कर देते हैं। यह तो बड़ी बुरी बात है। एक ही मशीन पर विभिन्न प्रकार की ड्राइव रह सकती हैं। और यदि फ़ाइल सिस्टम उनके बीच अंतर नहीं करेगा, तो कौन करेगा?

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

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

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

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

उसके बाद, आप डिवाइस C को अपने वॉल्यूम में जोड़ते हैं, और अंत में अपने सिस्टम को स्नैपशॉट S पर रोलबैक करते हैं। प्रश्न: S पर रोलबैक के बाद आपके लॉजिकल वॉल्यूम में कितनी फ़ाइलें और डिवाइस हैं? 100 फ़ाइलें होंगी, जैसा कि आपने अनुमान लगाया होगा, लेकिन 3 डिवाइस होंगी - ये वही डिवाइस ए, बी और सी हैं, हालाँकि जिस समय स्नैपशॉट बनाया गया था उस समय सिस्टम में केवल दो डिवाइस थे (ए और बी) ). ऐड डिवाइस सी ऑपरेशन वापस नहीं आया, और यदि आप अब डिवाइस सी को कंप्यूटर से हटाते हैं, तो यह आपके डेटा को दूषित कर देगा, इसलिए हटाने से पहले आपको डिवाइस को रीबैलेंस लॉजिकल वॉल्यूम से हटाने के लिए एक महंगा ऑपरेशन करने की आवश्यकता होगी, जो डिवाइस C से सभी डेटा को डिवाइस A और B में बिखेर देगा। लेकिन यदि आपका FS वैश्विक स्नैपशॉट का समर्थन करता है, तो ऐसे पुनर्संतुलन की आवश्यकता नहीं होगी, और S पर तत्काल रोलबैक के बाद, आप कंप्यूटर से डिवाइस C को सुरक्षित रूप से हटा सकते हैं।

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

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

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

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

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

कर्नेल ब्लॉक डिवाइस सबसिस्टम में परिवर्तन (उदाहरण के लिए, blk-mq की उपस्थिति) ने एफएस कार्यान्वयन की आवश्यकताओं को कैसे प्रभावित किया?

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

क्या नए प्रकार के मीडिया (उदाहरण के लिए, एसएमआर, या एसएसडी की सर्वव्यापकता) के उद्भव का मतलब फ़ाइल सिस्टम डिज़ाइन के लिए मौलिक रूप से नई चुनौतियाँ हैं?

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

आपके अलावा वर्तमान में कितने लोग Reiser4 कोड के साथ काम कर रहे हैं?

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

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

क्या किसी कंपनी ने Reiser4 के विकास में सहयोग देने की इच्छा व्यक्त की है?

हां, ऐसे प्रस्ताव थे, जिनमें शामिल हैं। और एक प्रमुख विक्रेता से. लेकिन इसके लिए मुझे दूसरे देश में जाना पड़ा. दुर्भाग्य से, मैं अब 30 साल का नहीं हूं, मैं पहली सीटी बजने पर इस तरह अलग होकर नहीं जा सकता।

Reiser4 में वर्तमान में कौन सी सुविधाएँ गायब हैं?

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

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

क्या आवश्यक सभी चीजें प्लगइन्स द्वारा कार्यान्वित की जा सकती हैं?

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

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

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

अब मुख्य प्रश्न पर - मुख्य कोर में Reiser4 के प्रचार के साथ चीजें कैसी चल रही हैं? क्या इस फ़ाइल सिस्टम की वास्तुकला पर कोई प्रकाशन था जिसके बारे में आपने पिछले साक्षात्कार में बात की थी? आपके दृष्टिकोण से यह प्रश्न कितना प्रासंगिक है?

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

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

पिछले कुछ वर्षों में Reiser4 में नया क्या है?

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

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

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

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

और अंत में, विषम तार्किक वॉल्यूम सामने आए हैं, जो वह सब कुछ प्रदान करते हैं जो ZFS, Btrfs, ब्लॉक लेयर, साथ ही FS+LVM संयोजन सिद्धांत रूप में प्रदान नहीं कर सकते हैं - समानांतर स्केलिंग, O(1) डिस्क एड्रेस एलोकेटर, सबवॉल्यूम के बीच पारदर्शी डेटा माइग्रेशन। बाद वाले में एक यूजर इंटरफ़ेस भी है। अब आप सबसे हॉट डेटा को अपने वॉल्यूम पर उच्चतम-प्रदर्शन वाली ड्राइव पर आसानी से ले जा सकते हैं।

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

अब तक मैं अपने विचारों को 10 प्रतिशत तक लागू करने में सक्षम रहा हूं, हालांकि, मैं उस काम में सफल रहा हूं जिसे मैंने सबसे कठिन माना था - तार्किक वॉल्यूम को एक फ्लैश प्रक्रिया के साथ जोड़ना जो reiser4 में सभी स्थगित कार्यों को निष्पादित करता है। यह सब अभी भी प्रायोगिक "प्रारूप41" शाखा में है।

क्या Reiser4 xfstests पास करता है?

कम से कम मेरे लिए ऐसा तब हुआ जब मैं आखिरी रिलीज की तैयारी कर रहा था।

क्या प्लगइन्स का उपयोग करके Reiser4 को एक नेटवर्क (क्लस्टर) FS बनाना सैद्धांतिक रूप से संभव है?

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

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

यदि Linux पर Reiser4 के साथ कुछ भी काम नहीं करता है, तो मैं FreeBSD के लिए एक FS की पेशकश करना चाहूंगा (पिछले साक्षात्कार से उद्धरण: "...FreeBSD... की अकादमिक जड़ें हैं... और इसका मतलब है कि उच्च स्तर की संभावना के साथ हम डेवलपर्स के साथ एक आम भाषा ढूंढेंगे")?

इसलिए, जैसा कि हमें अभी पता चला है, लिनक्स के साथ सब कुछ पहले से ही पूरी तरह से काम कर चुका है: हमारे रिपॉजिटरी की मास्टर शाखा के रूप में इसके लिए एक अलग काम करने वाला Reiser4 पोर्ट है। मैं FreeBSD के बारे में नहीं भूला हूँ! प्रस्ताव! मैं उन लोगों के साथ मिलकर काम करने के लिए तैयार हूं जो फ्रीबीएसडी के बारे में अच्छी तरह जानते हैं। वैसे: मुझे वास्तव में उनके समुदाय के बारे में जो पसंद है वह यह है कि वहां निर्णय स्वतंत्र विशेषज्ञों की एक अद्यतन परिषद द्वारा किए जाते हैं, जिसका एक स्थायी व्यक्ति के सरकारी धोखे से कोई लेना-देना नहीं है।

आप आज लिनक्स उपयोगकर्ता समुदाय का मूल्यांकन कैसे करते हैं? क्या यह और अधिक "पॉप" हो गया है?

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

क्या अगले पाँच से दस वर्षों के लिए फ़ाइल सिस्टम के विकास की भविष्यवाणी करना संभव है? आपके अनुसार एफएस डेवलपर्स को किन मुख्य चुनौतियों का सामना करना पड़ सकता है?

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

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

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

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

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

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

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

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

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

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

अंतिम परिणाम में किसी की रुचि नहीं होगी. बीस साल पहले, शायद, मेरी दिलचस्पी रही होगी, लेकिन अब सवाल अलग तरह से सामने आते हैं: क्या इसे बढ़ावा देना संभव होगा ताकि अगले दस वर्षों के भीतर कुछ लोगों को रोजगार मिल सके। और, अफसोस, अंतिम परिणाम के बारे में आश्चर्य करना प्रथागत नहीं है।

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

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

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

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

स्रोत: opennet.ru