Reiser4 FS चे विकसक एडवर्ड शिश्किन यांची दुसरी मुलाखत

Reiser4 फाइल सिस्टमचे विकसक एडवर्ड शिश्किन यांची दुसरी मुलाखत प्रकाशित झाली आहे.

सुरू करण्यासाठी, कृपया वाचकांना आठवण करून द्या की तुम्ही कुठे आणि कोणासाठी काम करता.

मी Huawei Technologies, German Research Center येथे प्रिन्सिपल स्टोरेज आर्किटेक्ट म्हणून काम करतो. व्हर्च्युअलायझेशन विभागात मी डेटा स्टोरेजच्या विविध बाबी हाताळतो. माझे क्रियाकलाप विशिष्ट ऑपरेटिंग सिस्टमशी संबंधित नाहीत.

तुम्ही सध्या मुख्य कर्नल शाखेत जात आहात?

अगदी क्वचितच, आणि माझ्या नियोक्त्याला त्याची आवश्यकता असेल तरच. शेवटची वेळ सुमारे तीन वर्षांपूर्वी होती, मी 9p प्रोटोकॉल (या व्यवसायाचे दुसरे नाव VirtFS आहे) वापरून होस्टवर शेअर केलेल्या स्टोरेजसाठी थ्रूपुट वाढवण्यासाठी पॅच पाठवले होते. येथे एक महत्त्वाची नोंद करणे आवश्यक आहे: जरी मी लिनक्समध्ये बर्याच काळापासून काम करत असलो तरी, मी त्याचा कधीही चाहता नव्हतो, म्हणजे, मी इतर सर्व गोष्टींप्रमाणे "समान श्वास घेतो". विशेषतः, जर मला काही दोष आढळला तर, मी ते एकदाच दाखवू शकतो. आणि जेणेकरून आपण नंतर एखाद्याचे अनुसरण करू शकता आणि त्यांचे मन वळवू शकता - असे होणार नाही.

मला आठवतंय गेल्या वेळी, दहा वर्षांपूर्वी, तुम्ही कर्नल डेव्हलपमेंट शैलीवर खूप टीका केली होती. तुमच्या (किंवा कदाचित कॉर्पोरेट) दृष्टिकोनातून, काही बदलले आहे का, समुदाय अधिक प्रतिसाद देणारा झाला आहे की नाही? नसेल तर दोषी कोण आहे असे तुम्हाला वाटते?

मी कधीही चांगल्यासाठी कोणतेही बदल पाहिले नाहीत. समाजाची मुख्य समस्या म्हणजे विज्ञानाच्या जागी राजकीय तंत्रज्ञान, वैयक्तिक संबंध, बहुसंख्य मत, लोकवाद, "आतल्या आवाजांचा सल्ला," कुजलेल्या तडजोडी, विज्ञान सोडून इतर काहीही. संगणक विज्ञान, कोणी काहीही म्हणो, प्रथम आणि सर्वात महत्त्वाचे म्हणजे अचूक विज्ञान आहे. आणि जर कोणी 2x2 साठी, 4 पेक्षा वेगळे, “Linux मार्ग” ध्वजाखाली किंवा इतर कोणत्याही ध्वजाखाली XNUMXxXNUMX साठी स्वतःचे मूल्य घोषित करू लागले, तर यामुळे हानीशिवाय दुसरे काहीही होण्याची शक्यता नाही.

सर्व त्रास मुख्यतः निर्णय घेणाऱ्यांच्या अक्षमतेमुळे आणि शिक्षणाच्या अभावामुळे आहेत. जर व्यवस्थापक अक्षम असेल तर तो वस्तुनिष्ठ, पुरेसा निर्णय घेऊ शकत नाही. जर तो देखील असंस्कृत असेल तर त्याला योग्य सल्ला देणारा सक्षम तज्ञ सापडत नाही. उच्च संभाव्यतेसह, निवड एखाद्या स्कॅमरवर पडेल जो "उशिर योग्य गोष्टी" म्हणतो. एक भ्रष्ट वातावरण नेहमीच अक्षम एकाकी नेत्यांभोवती निर्माण होते. शिवाय, इतिहासाला या संदर्भात अपवाद नाही, आणि समुदाय याला सर्वात स्पष्ट पुष्टी देतो.

तुम्ही Btrfs विकासातील प्रगतीचे मूल्यांकन कसे करता? या एफएसमुळे बालपणातील आजारांपासून सुटका झाली का? तुम्ही ते स्वतःसाठी कसे ठेवता - FS म्हणून “घरासाठी” किंवा कॉर्पोरेट वापरासाठी देखील?

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

हे असे दिसते (लिनक्स कर्नल 5.12 साठी चाचणी केलेले). स्क्रिप्ट नव्याने स्थापित केलेल्या सिस्टमवर लॉन्च केली जाते, जी लूपमध्ये होम डिरेक्टरीमध्ये विशिष्ट नावांच्या फायली तयार करते, त्यांना विशिष्ट ऑफसेटवर डेटा लिहिते आणि नंतर या फायली हटवते. ही स्क्रिप्ट चालवल्यानंतर एक मिनिटानंतर, असामान्य काहीही घडत नाही. पाच मिनिटांनंतर, विभाजनावरील व्यापलेल्या जागेचा भाग किंचित वाढतो. दोन ते तीन तासांनंतर ते 50% पर्यंत पोहोचते (15% च्या प्रारंभिक मूल्यासह). आणि पाच किंवा सहा तासांच्या कामानंतर, स्क्रिप्ट "विभाजनावर मोकळी जागा नाही" या त्रुटीसह क्रॅश होते. यानंतर, तुम्ही यापुढे तुमच्या विभाजनावर 4K फाइल देखील लिहू शकणार नाही.

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

शिवाय, हे सर्व मूलभूत Btrfs कॉन्फिगरेशनवर (कोणत्याही स्नॅपशॉट्स, सबव्हॉल्यूम्स इ. शिवाय) आधीपासून घडते, आणि तुम्ही त्या FS मध्ये फाइल बॉडी कसे संग्रहित करायचे हे महत्त्वाचे नाही (झाडातील “तुकड्यांच्या” रूपात, किंवा विस्तार म्हणून. अनफॉर्मेट ब्लॉक्सचे) - अंतिम परिणाम समान असेल.

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

सामूहिक सर्व्हरवर, आक्रमणकर्ता नेहमी त्यांच्या "पुढे जाण्यास" सक्षम असेल. त्याला नक्की कोणी धमकावले हे सिस्टीम प्रशासक देखील ठरवू शकणार नाही. Btrfs मध्ये या समस्येचे निराकरण करण्याचा सर्वात जलद मार्ग म्हणजे नियमित बी-ट्रीची संरचना पुनर्संचयित करणे, म्हणजे. डिस्क स्वरूपाची पुनर्रचना करणे आणि Btrfs कोडचे महत्त्वपूर्ण भाग पुनर्लेखन करणे. यास डीबगिंगसह 8-10 वर्षे लागतील, जर डेव्हलपरने संबंधित अल्गोरिदम आणि डेटा स्ट्रक्चर्सवरील मूळ लेखांचे काटेकोरपणे पालन केले असेल आणि “लिनक्स मधील रूढीप्रमाणे (आणि प्रोत्साहन दिलेला) “तुटलेला फोन” गेम खेळला नाही. मार्ग".

हे सर्व समजून घेण्यासाठी डेव्हलपरला लागणारा वेळही इथे जोडावा लागेल. इथेच ते अधिक कठीण होते. कोणत्याही परिस्थितीत, त्यांना समजण्यासाठी 10 वर्षे पुरेशी नव्हती. बरं, तोपर्यंत तुम्ही चमत्काराची आशा करू शकत नाही. हे माउंटिंग पर्यायाच्या रूपात होणार नाही “ज्याबद्दल तुम्हाला आणि मला माहित नव्हते,” किंवा पॅचच्या स्वरूपात जे तयार करणे “फक्त व्यवसायाची बाब आहे”. अशा प्रत्येक उतावीळ "निराकरण" साठी मी अध:पतनाची एक नवीन परिस्थिती सादर करेन. बी-ट्रीज हा माझा आवडता विषय आहे आणि मला असे म्हणायचे आहे की या रचना स्वतःला स्वातंत्र्य सहन करत नाहीत!

मी स्वतःसाठी Btrf कसे ठेवू? ज्याला फाईल सिस्टीम म्हणता येणार नाही असे काहीतरी म्हणून, वापरले तर सोडा. कारण, व्याख्येनुसार, FS एक OS उपप्रणाली आहे जी "डिस्क स्पेस" संसाधनाच्या प्रभावी व्यवस्थापनासाठी जबाबदार आहे, जी आम्हाला Btrfs च्या बाबतीत दिसत नाही. बरं, कल्पना करा की कामाला उशीर होऊ नये म्हणून तुम्ही घड्याळ खरेदी करण्यासाठी स्टोअरमध्ये आला आहात आणि घड्याळाऐवजी त्यांनी तुम्हाला जास्तीत जास्त 30 मिनिटांसाठी टायमर असलेली इलेक्ट्रिक ग्रिल विकली. तर, Btrfs ची परिस्थिती आणखी वाईट आहे.

मेलिंग लिस्ट पाहत असताना, मला अनेकदा असे विधान आढळते की ड्राइव्हच्या स्वस्ततेमुळे डिस्क स्पेस प्रभावीपणे व्यवस्थापित करणे यापुढे संबंधित नाही. हा पूर्ण मूर्खपणा आहे. प्रभावी डिस्क स्पेस व्यवस्थापकाशिवाय, OS असुरक्षित आणि निरुपयोगी होईल. तुमच्या मशीनवरील डिस्कची क्षमता कितीही असली तरी.

मी RHEL मधील Btrfs समर्थन बंद करण्याबद्दल टिप्पणी विचारू इच्छितो.

येथे टिप्पणी करण्यासारखे काही विशेष नाही, सर्वकाही अगदी स्पष्ट आहे. त्यांच्याकडे ते "तंत्रज्ञान पूर्वावलोकन" म्हणून देखील होते. म्हणून, मी या "पूर्वावलोकन" मधून गेलो नाही. हे लेबल कायमचे लटकू देऊ नका! परंतु ते पूर्ण समर्थनासह सदोष बाय-डिझाइन उत्पादन लाँच करू शकत नाहीत. RHEL एक एंटरप्राइझ आहे, म्हणजे, निर्धारित वस्तू-पैसा संबंध. Red Hat वापरकर्त्यांना ते Btrfs मेलिंग लिस्ट प्रमाणे धमकावू शकत नाही. फक्त परिस्थितीची कल्पना करा: ज्या क्लायंटने आपल्या हार्ड कमाईचे पैसे डिस्कसाठी आणि तुम्हाला समर्थनासाठी दिले आहेत, त्याला हे समजून घ्यायचे आहे की त्याने काहीही न लिहिल्यानंतर त्याची डिस्क स्पेस कुठे गेली. यावर तुम्ही त्याला काय उत्तर देणार?

पुढील. Red Hat च्या क्लायंटमध्ये सुप्रसिद्ध मोठ्या बँका आणि एक्सचेंजेसचा समावेश होतो. Btrfs मधील नमूद केलेल्या भेद्यतेवर आधारित ते DoS हल्ल्यांच्या अधीन असल्यास काय होईल याची कल्पना करा. याला जबाबदार कोण असे तुम्हाला वाटते? जे जीपीएल परवान्याच्या रेषेकडे बोट दाखवणार आहेत, जिथे असे लिहिले आहे की लेखक कशासाठीही जबाबदार नाही, मी लगेच म्हणेन: "ते लपवा!" Red Hat उत्तर देईल, आणि अशा प्रकारे की ते पुरेसे वाटणार नाही! परंतु मला माहित आहे की, माझ्या काळात मला जवळून काम करण्याची संधी असलेल्या QA अभियंत्यांच्या त्यांच्या विशेषत: मजबूत टीममुळे, Red Hat ला अशा प्रकारच्या समस्येचा सामना करावा लागत नाही.

काही कंपन्या त्यांच्या एंटरप्राइझ उत्पादनांमध्ये Btrf चे समर्थन का करत आहेत?

कृपया लक्षात घ्या की उत्पादनाच्या नावातील उपसर्ग "एंटरप्राइज" चा अर्थ जास्त नाही. एंटरप्राइझ हे क्लायंटशी कराराच्या संबंधात अंतर्भूत जबाबदारीचे एक माप आहे. मला GNU/Linux वर आधारित फक्त एक एंटरप्राइझ माहित आहे - RHEL. बाकी सर्व काही, माझ्या दृष्टिकोनातून, फक्त एक एंटरप्राइझ म्हणून सादर केले जाते, परंतु एक नाही. आणि शेवटी, जर एखाद्या गोष्टीची मागणी असेल तर नेहमीच पुरवठा असेल (आमच्या बाबतीत, हे उल्लेखित "समर्थन" आहे). अगदी सर्व गोष्टींची मागणी आहे, यासह. आणि निरुपयोगी सॉफ्टवेअर. अशी मागणी कशी निर्माण होते आणि त्याला कोण शह देते हा दुसरा विषय आहे.

त्यामुळे, फेसबुकने त्याच्या सर्व्हरवर Btrfs तैनात केल्याची अफवा पसरल्यानंतर मी कोणत्याही निष्कर्षावर जाणार नाही. शिवाय, मी वरील कारणांसाठी त्या सर्व्हरचे पत्ते काळजीपूर्वक गुप्त ठेवण्याची शिफारस करतो.

अलीकडे XFS कोड साफ करण्यासाठी इतके प्रयत्न का केले गेले आहेत? शेवटी, सुरुवातीला ही तृतीय-पक्ष फाइल प्रणाली आहे, आणि ext4 बर्याच काळापासून स्थिर आहे आणि पूर्वीच्या समान स्थिर आवृत्त्यांमधून सातत्य आहे. Red Hat ला XFS मध्ये काय स्वारस्य आहे? ext4 आणि XFS - उद्देशाने समान असलेल्या दोन फाइल प्रणाली सक्रियपणे विकसित करण्यात अर्थ आहे का?

हे कशामुळे प्रेरित झाले ते मला आठवत नाही. हे शक्य आहे की पुढाकार Red Hat क्लायंटकडून आला आहे. मला आठवते की या प्रकारचे संशोधन केले गेले: अपस्ट्रीममधील काही फाइल सिस्टमवर, नवीन पिढीच्या हाय-एंड ड्राइव्हवर मोठ्या संख्येने ऑब्जेक्ट्स तयार केल्या गेल्या. परिणामांनुसार, XFS ext4 पेक्षा चांगले वागले. त्यामुळे ते सर्वात आश्वासक म्हणून त्याचा प्रचार करू लागले. कोणत्याही परिस्थितीत, मी येथे सनसनाटी काहीही शोधणार नाही.

माझ्यासाठी, त्यांनी साबणाने awl बदलल्यासारखे आहे. ext4 आणि XFS विकसित करण्यात काही अर्थ नाही. दोन्ही समांतर आणि निवडण्यासाठी त्यापैकी कोणतेही. यातून काहीही चांगले होणार नाही. जरी, निसर्गात अनेकदा अशी परिस्थिती असते जेव्हा वाढीसाठी भरपूर क्षमता असते, परंतु वाढण्यास जागा नसते. या प्रकरणात, विविध विचित्रपणे कुरुप नवीन वाढ उद्भवतात, ज्याकडे प्रत्येकजण बोट दाखवतो ("अरे, पहा, या जीवनात तुम्हाला काय दिसणार नाही!").

ext4, F2FS (Btrfs मध्ये RAID चा उल्लेख करू नये) मधील एन्क्रिप्शन फंक्शन्सच्या आगमनाने लेयर उल्लंघनाची समस्या (नकारार्थी अर्थाने) निकाली निघाली आहे असे तुम्हाला वाटते का?

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

उदाहरणार्थ, मिररिंग, जे परंपरेने ब्लॉक लेयरसाठी एक क्रियाकलाप आहे, फाइल सिस्टम स्तरावर अंमलबजावणी करणे अर्थपूर्ण आहे. वेगवेगळ्या कारणांसाठी. उदाहरणार्थ, डिस्क ड्राइव्हवर "सायलेंट" डेटा करप्ट (बिट रॉट) होतो. जेव्हा डिव्हाइस योग्यरित्या कार्य करत असते तेव्हा हे घडते, परंतु दूरस्थ क्वासार इत्यादीद्वारे उत्सर्जित केलेल्या हार्ड गामा क्वांटमच्या प्रभावाखाली ब्लॉक डेटा अनपेक्षितपणे खराब होतो. सर्वात वाईट गोष्ट म्हणजे जर हा ब्लॉक FS सिस्टम ब्लॉक (सुपरब्लॉक, बिटमॅप ब्लॉक, स्टोरेज ट्री नोड, इ.) असेल, कारण यामुळे नक्कीच कर्नल पॅनिक होईल.

कृपया लक्षात घ्या की ब्लॉक लेयर (तथाकथित RAID 1) द्वारे ऑफर केलेले मिरर तुम्हाला या समस्येपासून वाचवणार नाहीत. बरं, खरोखर: कोणीतरी चेकसम तपासले पाहिजे आणि अयशस्वी झाल्यास प्रतिकृती वाचली पाहिजे? याव्यतिरिक्त, केवळ सर्वकाहीच नव्हे तर केवळ मेटाडेटा मिरर करणे अर्थपूर्ण आहे. काही महत्त्वाचा डेटा (उदाहरणार्थ, गंभीर ऍप्लिकेशन्सच्या एक्झिक्यूटेबल फाइल्स) मेटाडेटा म्हणून संग्रहित केला जाऊ शकतो. या प्रकरणात, त्यांना सुरक्षिततेची समान हमी मिळते. उर्वरित डेटाचे संरक्षण इतर उपप्रणालींना (कदाचित वापरकर्ता अनुप्रयोग देखील) सोपविणे अर्थपूर्ण आहे - आम्ही यासाठी सर्व आवश्यक अटी प्रदान केल्या आहेत.

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

Reiser4 वर “खाली पासून” पातळीचे उल्लंघन केल्याचा आरोप होता. फाईल सिस्टीम इतर सर्वांप्रमाणे मोनोलिथिक नसून मॉड्यूलर आहे या वस्तुस्थितीच्या आधारावर, वरील पातळी (VFS) ने जे करावे तेच ती करते असे एक अप्रमाणित गृहितक बांधले गेले.

ReiserFS v3.6 आणि उदाहरणार्थ, JFS च्या मृत्यूबद्दल बोलणे शक्य आहे का? अलीकडे त्यांच्याकडे जवळजवळ लक्ष दिले गेले नाही. ते अप्रचलित आहेत?

येथे आपल्याला सॉफ्टवेअर उत्पादनाच्या मृत्यूचा अर्थ काय आहे ते परिभाषित करणे आवश्यक आहे. एकीकडे, ते यशस्वीरित्या वापरले जातात (त्यासाठीच ते तयार केले गेले होते, शेवटी), याचा अर्थ ते जगतात. दुसरीकडे, मी JFS साठी बोलू शकत नाही (मला जास्त माहिती नाही), परंतु ReiserFS (v3) नवीन ट्रेंडशी जुळवून घेणे खूप कठीण आहे (सराव मध्ये चाचणी केली). याचा अर्थ असा आहे की भविष्यात विकसक त्याकडे लक्ष देत नाहीत, परंतु ज्यांना अनुकूल करणे सोपे आहे त्यांच्याकडे. या बाजूने असे दिसून आले की, अरेरे, वास्तुशास्त्राच्या दृष्टीने ते मृत आहे. मी "नैतिकदृष्ट्या अप्रचलित" संकल्पना अजिबात हाताळणार नाही. हे चांगले लागू होते, उदाहरणार्थ, वॉर्डरोबवर, परंतु सॉफ्टवेअर उत्पादनांवर नाही. एखाद्या गोष्टीत कनिष्ठता आणि श्रेष्ठत्वाची संकल्पना असते. मी पूर्णपणे म्हणू शकतो की ReserFS v3 आता सर्व गोष्टींमध्ये Reiser4 पेक्षा निकृष्ट आहे, परंतु काही प्रकारच्या वर्कलोडमध्ये ते इतर सर्व अपस्ट्रीम FSs पेक्षा श्रेष्ठ आहे.

तुम्हाला FS Tux3 आणि HAMMER/HAMMER2 (FS for DragonFly BSD) च्या विकासाबद्दल माहिती आहे का?

होय, आम्हाला माहित आहे. Tux3 मध्ये मला त्यांच्या स्नॅपशॉट्सच्या तंत्रज्ञानामध्ये (तथाकथित "आवृत्ती पॉइंटर्स") रस होता, परंतु Reiser4 मध्ये आम्ही बहुधा वेगळ्या मार्गावर जाऊ. मी बऱ्याच काळापासून स्नॅपशॉटला समर्थन देण्याबद्दल विचार करत आहे आणि साध्या Reiser4 व्हॉल्यूमसाठी ते कसे अंमलात आणायचे हे अद्याप ठरवले नाही. वस्तुस्थिती अशी आहे की ओहद रोडेहने प्रस्तावित केलेले नवीन "आळशी" संदर्भ काउंटर तंत्र केवळ बी-ट्रीजसाठी कार्य करते. आमच्याकडे ते नाहीत. Reiesr4 मध्ये वापरल्या जाणाऱ्या डेटा स्ट्रक्चर्ससाठी, "आळशी" काउंटर परिभाषित केलेले नाहीत - त्यांचा परिचय देण्यासाठी, काही अल्गोरिदमिक समस्या सोडवणे आवश्यक आहे, ज्या अद्याप कोणीही स्वीकारल्या नाहीत.

हॅमरच्या मते: मी निर्मात्याचा एक लेख वाचला. रस नाही. पुन्हा, बी-झाडे. ही डेटा रचना हताशपणे जुनी आहे. गेल्या शतकात आम्ही ते सोडून दिले.

CephFS/GlusterFS/etc सारख्या नेटवर्क क्लस्टर FS च्या वाढत्या मागणीचे तुम्ही कसे मूल्यांकन करता? या मागणीचा अर्थ नेटवर्क FS कडे विकासकांच्या प्राधान्यक्रमात बदल आणि स्थानिक FS कडे अपुरे लक्ष आहे का?

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

त्यामुळे त्या भागात अजूनही बरेच काम असले तरी स्थानिक एफएसकडे लक्ष दिले जात नाही. आणि हो, प्रत्येकजण वितरित स्टोरेजकडे वळला आहे, जो आधीपासून अस्तित्वात असलेल्या स्थानिक फाइल सिस्टमच्या आधारावर तयार केला गेला आहे. हे आता खूप फॅशनेबल आहे. "बिग डेटा" या वाक्यांशामुळे अनेकांसाठी एड्रेनालाईन गर्दी होते, ती परिषद, कार्यशाळा, मोठे पगार इत्यादींशी संबंधित आहे.

युजर स्पेस ऐवजी कर्नल स्पेसमध्ये नेटवर्क फाइल सिस्टमची अंमलबजावणी करणे तत्त्वतः कितपत वाजवी आहे?

एक अतिशय वाजवी दृष्टीकोन जो अद्याप कुठेही लागू केलेला नाही. सर्वसाधारणपणे, नेटवर्क फाइल सिस्टम कोणत्या जागेत कार्यान्वित करावी हा प्रश्न "दुधारी तलवार" आहे. बरं, एक उदाहरण पाहू. क्लायंटने रिमोट मशीनवर डेटा रेकॉर्ड केला. ते गलिच्छ पृष्ठांच्या रूपात तिच्या पृष्ठाच्या कॅशेमध्ये पडले. कर्नल स्पेसमधील "पातळ गेटवे" नेटवर्क फाइल सिस्टमसाठी हे काम आहे. मग ऑपरेटिंग सिस्टम लवकरच किंवा नंतर तुम्हाला ती पृष्ठे मुक्त करण्यासाठी डिस्कवर लिहिण्यास सांगेल. नंतर IO-फॉरवर्डिंग (पाठवणे) नेटवर्क FS मॉड्यूल कार्यात येईल. ही पृष्ठे कोणत्या सर्व्हर मशीनवर (सर्व्हर नोड) जातील हे ते ठरवते.

मग नेटवर्क स्टॅक ताब्यात घेते (आणि, जसे आपल्याला माहित आहे, ते कर्नल स्पेसमध्ये लागू केले जाते). पुढे, सर्व्हर नोड डेटा किंवा मेटाडेटासह पॅकेट प्राप्त करतो आणि बॅकएंड स्टोरेज मॉड्यूलला (म्हणजे, कर्नल स्पेसमध्ये कार्यरत स्थानिक FS) या सर्व गोष्टी रेकॉर्ड करण्यासाठी निर्देश देतो. म्हणून, आम्ही प्रश्न कमी केला आहे की "पाठवणे" आणि "प्राप्त करणे" मॉड्यूल कुठे कार्य करावे. यापैकी कोणतेही मॉड्यूल वापरकर्त्याच्या जागेत चालत असल्यास, हे अपरिहार्यपणे संदर्भ स्विचिंगकडे नेईल (कर्नल सेवा वापरण्याची आवश्यकता असल्यामुळे). अशा स्विचची संख्या अंमलबजावणी तपशीलांवर अवलंबून असते.

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

हे, अर्थातच, नेटवर्क एफएस नाही, परंतु ते गोष्टींचे सार पूर्णपणे प्रतिबिंबित करते. या ऑप्टिमायझेशनची नकारात्मक बाजू म्हणजे पोर्टेबिलिटी समस्या. काहींसाठी, नंतरचे गंभीर असू शकते. उदाहरणार्थ, GlusterFS मध्ये कर्नलमध्ये कोणतेही मॉड्यूल नाहीत. याबद्दल धन्यवाद, ते आता नेटबीएसडीसह अनेक प्लॅटफॉर्मवर कार्य करते.

स्थानिक FS कोणत्या संकल्पना नेटवर्क कडून घेऊ शकतात आणि त्याउलट?

आजकाल, नेटवर्क FSs, नियमानुसार, स्थानिक FSs वर ऍड-ऑन असतात, त्यामुळे तुम्ही नंतरचे काहीतरी कसे घेऊ शकता हे मला समजत नाही. बरं, खरंच, 4 कर्मचाऱ्यांच्या कंपनीचा विचार करूया, ज्यामध्ये प्रत्येकजण स्वतःचे कार्य करतो: एक वितरण करतो, दुसरा पाठवतो, तिसरा प्राप्त करतो, चौथा स्टोअर. आणि प्रश्न, कंपनी आपल्या कर्मचाऱ्याकडून काय कर्ज घेऊ शकते जो ते संग्रहित करतो, तो कसा तरी चुकीचा वाटतो (त्याच्याकडे आधीपासूनच त्याच्याकडून बरेच दिवस कर्ज घेतले जाऊ शकते).

परंतु स्थानिक FS ला नेटवर्क कडून बरेच काही शिकायचे आहे. प्रथम, आपण त्यांच्याकडून उच्च स्तरावर तार्किक खंड कसे एकत्रित करावे हे शिकले पाहिजे. आता तथाकथित "प्रगत" स्थानिक फाइल प्रणाली LVM कडून घेतलेल्या "व्हर्च्युअल डिव्हाइस" तंत्रज्ञानाचा वापर करून लॉजिकल व्हॉल्यूम एकत्रित करतात (तेच संसर्गजन्य लेयरिंग उल्लंघन जे प्रथम ZFS मध्ये लागू केले गेले होते). दुसऱ्या शब्दांत, आभासी पत्त्यांचे (ब्लॉक क्रमांक) वास्तविक पत्त्यांमध्ये भाषांतर आणि परत कमी पातळीवर होते (म्हणजे, फाइल सिस्टमने I/O विनंती जारी केल्यानंतर).

कृपया लक्षात घ्या की ब्लॉक लेयरवर व्यवस्था केलेल्या लॉजिकल व्हॉल्यूममध्ये (मिरर नाही) डिव्हाइस जोडणे आणि काढणे यामुळे अशा समस्या उद्भवतात ज्याबद्दल अशा "वैशिष्ट्यांचे" पुरवठादार शांतपणे शांत असतात. मी वास्तविक उपकरणांवरील विखंडन बद्दल बोलत आहे, जे राक्षसी मूल्यांपर्यंत पोहोचू शकते, तर आभासी डिव्हाइसवर सर्वकाही ठीक आहे. तथापि, काही लोकांना व्हर्च्युअल उपकरणांमध्ये स्वारस्य आहे: प्रत्येकाला आपल्या वास्तविक उपकरणांवर काय चालले आहे यात स्वारस्य आहे. परंतु ZFS सारखी FS (तसेच LVM च्या संयोगाने कोणतेही FS) फक्त व्हर्च्युअल डिस्क उपकरणांसह कार्य करते (विनामूल्य मधून व्हर्च्युअल डिस्क पत्ते वाटप करा, ही आभासी उपकरणे डीफ्रॅगमेंट करा इ.). आणि वास्तविक उपकरणांवर काय चालले आहे याची त्यांना कल्पना नाही!

आता कल्पना करा की तुमच्याकडे व्हर्च्युअल डिव्हाइसवर शून्य विखंडन आहे (म्हणजेच, तुमच्याकडे फक्त एक विशाल विस्तार आहे), तुम्ही तुमच्या लॉजिकल व्हॉल्यूममध्ये डिस्क जोडता, आणि नंतर तुमच्या लॉजिकल व्हॉल्यूममधून दुसरी यादृच्छिक डिस्क काढून टाका आणि नंतर पुन्हा संतुलित करा. आणि अनेक वेळा. व्हर्च्युअल डिव्हाइसवर तुम्ही अजूनही तितकेच जगत असल्याची कल्पना करणे कठिण नाही, परंतु रिअल डिव्हाइसवर तुम्हाला काहीही चांगले दिसणार नाही.

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

याशिवाय, स्वतंत्र FS+LVM उपप्रणालीचे संयोजन ज्या ड्राईव्हमधून लॉजिकल व्हॉल्यूम एकत्रित केले जातात त्याचे भिन्न स्वरूप विचारात घेण्यास परवानगी देत ​​नाही. खरंच, समजा तुम्ही HDD आणि सॉलिड-स्टेट डिव्हाइसेसवरून लॉजिकल व्हॉल्यूम एकत्र केला आहे. परंतु नंतर पूर्वीचे डीफ्रॅगमेंटेशन आवश्यक असेल आणि नंतरचे नाही. नंतरच्यासाठी, तुम्हाला टाकून देण्याच्या विनंत्या जारी करणे आवश्यक आहे, परंतु पूर्वीसाठी नाही, इ. तथापि, या संयोजनात अशी निवडकता प्रदर्शित करणे खूप कठीण आहे.

लक्षात घ्या की फाइल प्रणालीवर तुमचे स्वतःचे LVM निर्माण केल्यानंतर, परिस्थिती फारशी चांगली होत नाही. शिवाय, असे केल्याने तुम्ही भविष्यात त्यात कधीही सुधारणा करण्याची शक्यता संपुष्टात आणता. हे खूप वाईट आहे. वेगवेगळ्या प्रकारचे ड्राइव्ह एकाच मशीनवर राहू शकतात. आणि जर फाइल सिस्टम त्यांच्यात फरक करत नसेल तर कोण करेल?

दुसरी समस्या तथाकथित प्रतीक्षेत आहे. "कोठेही लिहा" फाइल सिस्टम (यामध्ये Reiser4 देखील समाविष्ट आहे, जर तुम्ही माउंट दरम्यान योग्य व्यवहार मॉडेल निर्दिष्ट केले असेल). अशा फाइल सिस्टीमने डीफ्रॅगमेंटेशन साधने प्रदान केली पाहिजे जी त्यांच्या सामर्थ्यामध्ये अभूतपूर्व आहेत. आणि निम्न-स्तरीय व्हॉल्यूम व्यवस्थापक येथे मदत करत नाही, परंतु केवळ मार्गात येतो. वस्तुस्थिती अशी आहे की अशा व्यवस्थापकासह, आपला FS फक्त एका डिव्हाइसच्या विनामूल्य ब्लॉक्सचा नकाशा संग्रहित करेल - एक आभासी. त्यानुसार, तुम्ही केवळ व्हर्च्युअल डिव्हाइस डीफ्रॅगमेंट करू शकता. याचा अर्थ असा की तुमचा डीफ्रॅगमेंटर व्हर्च्युअल पत्त्यांच्या एका प्रचंड जागेवर दीर्घकाळ, दीर्घकाळ काम करेल.

आणि जर तुमच्याकडे बरेच वापरकर्ते यादृच्छिक ओव्हरराईट करत असतील तर अशा डीफ्रॅगमेंटरचा उपयुक्त प्रभाव शून्यावर कमी होईल. तुमची प्रणाली अपरिहार्यपणे मंद होण्यास सुरुवात करेल आणि तुम्हाला निराशाजनक निदान "तुटलेली रचना" समोर आपले हात जोडावे लागतील. एकाच ॲड्रेस स्पेसवर चालणारे अनेक डीफ्रॅगमेंटर्स केवळ एकमेकांमध्ये व्यत्यय आणतील. आपण प्रत्येक वास्तविक डिव्हाइससाठी विनामूल्य ब्लॉक्सचा स्वतःचा नकाशा राखल्यास ही एक पूर्णपणे वेगळी बाब आहे. हे डीफ्रॅगमेंटेशन प्रक्रियेस प्रभावीपणे समांतर करेल.

परंतु हे केवळ तेव्हाच केले जाऊ शकते जेव्हा आपल्याकडे उच्च-स्तरीय तार्किक व्हॉल्यूम व्यवस्थापक असेल. अशा व्यवस्थापकांसह स्थानिक फाइल सिस्टम पूर्वी अस्तित्वात नव्हते (किमान, मला त्यांच्याबद्दल माहित नाही). फक्त नेटवर्क फाइल सिस्टममध्ये (उदाहरणार्थ GlusterFS) असे व्यवस्थापक होते. दुसरे अतिशय महत्त्वाचे उदाहरण म्हणजे व्हॉल्यूम इंटिग्रिटी चेक (fsck) युटिलिटी. आपण प्रत्येक सबव्हॉल्यूमसाठी विनामूल्य ब्लॉक्सचा स्वतंत्र नकाशा संग्रहित केल्यास, तार्किक व्हॉल्यूम तपासण्याची प्रक्रिया प्रभावीपणे समांतर केली जाऊ शकते. दुसऱ्या शब्दांत, उच्च-स्तरीय व्यवस्थापकांसह तार्किक खंड अधिक चांगले स्केल करतात.

याव्यतिरिक्त, निम्न-स्तरीय व्हॉल्यूम व्यवस्थापकांसह आपण पूर्ण वाढलेले स्नॅपशॉट आयोजित करण्यास सक्षम राहणार नाही. LVM आणि ZFS-सदृश फाइल प्रणालीसह, तुम्ही फक्त स्थानिक स्नॅपशॉट घेऊ शकता, परंतु जागतिक स्नॅपशॉट्स घेऊ शकत नाही. स्थानिक स्नॅपशॉट्स तुम्हाला फक्त नियमित फाइल ऑपरेशन्स त्वरित रोल बॅक करण्याची परवानगी देतात. आणि तेथे कोणीही लॉजिकल व्हॉल्यूम (डिव्हाइस जोडणे/काढणे) सह ऑपरेशन्स परत करणार नाही. हे उदाहरणासह पाहू. काही वेळेस, जेव्हा तुमच्याकडे 100 फाइल्स असलेली दोन उपकरणे A आणि B चे लॉजिकल व्हॉल्यूम असते, तेव्हा तुम्ही सिस्टम S चा स्नॅपशॉट घ्या आणि नंतर आणखी शंभर फाइल्स तयार करा.

त्यानंतर, तुम्ही तुमच्या व्हॉल्यूममध्ये डिव्हाइस C जोडता आणि शेवटी तुमची सिस्टीम स्नॅपशॉट S मध्ये रोलबॅक करा. प्रश्न: S मध्ये रोलबॅक केल्यानंतर तुमच्या लॉजिकल व्हॉल्यूममध्ये किती फाइल्स आणि डिव्हाइसेस असतात? 100 फायली असतील, जसे तुम्ही अंदाज लावला असेल, परंतु तेथे 3 उपकरणे असतील - ही समान उपकरणे A, B आणि C आहेत, जरी स्नॅपशॉट तयार झाला तेव्हा सिस्टममध्ये फक्त दोन उपकरणे होती (A आणि B ). ॲड डिव्हाईस सी ऑपरेशन पुन्हा रोल बॅक झाले नाही आणि तुम्ही आता कॉम्प्युटरवरून डिव्हाइस सी काढून टाकल्यास, ते तुमचा डेटा खराब करेल, म्हणून डिलीट करण्यापूर्वी तुम्हाला तार्किक व्हॉल्यूमच्या पुनर्संतुलनातून डिव्हाइस काढून टाकण्यासाठी प्रथम महाग ऑपरेशन करावे लागेल, जे डिव्हाइस C ते डिव्हाइस A आणि B पर्यंत सर्व डेटा विखुरेल. परंतु तुमच्या FS ने जागतिक स्नॅपशॉटला सपोर्ट करत असल्यास, अशा रीबॅलेंसिंगची आवश्यकता नाही आणि S वर झटपट रोलबॅक केल्यानंतर, तुम्ही संगणकावरून डिव्हाइस C सुरक्षितपणे काढून टाकू शकता.

त्यामुळे, ग्लोबल स्नॅपशॉट्स चांगले आहेत कारण ते तुम्हाला लॉजिकल व्हॉल्यूममधून (लॉजिकल व्हॉल्यूममध्ये) मोठ्या प्रमाणात डेटा (अर्थातच, जर तुम्हाला तुमच्या सिस्टमला “स्नॅपशॉट” करणे आठवत असेल तर) खर्चिक काढून टाकणे (जोडणे) टाळता येते. योग्य वेळी). मी तुम्हाला आठवण करून देतो की स्नॅपशॉट्स तयार करणे आणि फाइल सिस्टम त्यांच्याकडे परत आणणे ही तात्काळ क्रिया आहेत. प्रश्न उद्भवू शकतो: तुम्हाला तीन दिवस लागलेल्या लॉजिकल व्हॉल्यूमवर ऑपरेशन त्वरित परत करणे कसे शक्य आहे? पण शक्य आहे! तुमची फाईल सिस्टीम योग्यरितीने डिझाइन केलेली असेल तर. मला अशा "3D स्नॅपशॉट्स" ची कल्पना तीन वर्षांपूर्वी सुचली आणि गेल्या वर्षी मी या तंत्राचे पेटंट घेतले.

पुढील गोष्ट जी स्थानिक FS ने नेटवर्क्सकडून शिकली पाहिजे ती म्हणजे मेटाडेटा वेगळ्या उपकरणांवर संग्रहित करणे ज्या प्रकारे नेटवर्क FS त्यांना वेगळ्या मशीनवर (तथाकथित मेटाडेटा सर्व्हर) संग्रहित करतात. असे ऍप्लिकेशन्स आहेत जे प्रामुख्याने मेटाडेटासह कार्य करतात आणि हे ऍप्लिकेशन्स महागड्या उच्च-कार्यक्षमता स्टोरेज डिव्हाइसेसवर मेटाडेटा ठेवून खूप वेगवान केले जाऊ शकतात. FS+LVM संयोगाने, तुम्ही अशी निवडकता प्रदर्शित करू शकणार नाही: LVM ला तुम्ही दिलेल्या ब्लॉकवर काय आहे हे माहीत नाही (तेथे डेटा किंवा मेटाडेटा).

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

पूर्णपणे भयानक अल्गोरिदमची उदाहरणे म्हणजे GlusterFS फाइल सिस्टममधील DHT अनुवादक आणि Ceph फाइल सिस्टममध्ये तथाकथित CRUSH नकाशा. मी पाहिलेल्या कोणत्याही अल्गोरिदमने मला साधेपणा आणि चांगल्या स्केलेबिलिटीच्या बाबतीत समाधान दिले नाही. म्हणून मला बीजगणित लक्षात ठेवावे लागले आणि प्रत्येक गोष्टीचा स्वतः शोध घ्यावा लागला. 2015 मध्ये, हॅश फंक्शन्सवर बंडलचा प्रयोग करत असताना, मी माझ्यासाठी उपयुक्त असे काहीतरी आणले आणि पेटंट केले. आता हे सर्व प्रत्यक्षात उतरवण्याचा प्रयत्न यशस्वी झाला असे मी म्हणू शकतो. मला नवीन दृष्टिकोनामध्ये स्केलेबिलिटीसह कोणतीही समस्या दिसत नाही.

होय, प्रत्येक सबव्हॉल्यूमला मेमरीमधील सुपरब्लॉक सारखी वेगळी रचना आवश्यक असेल. हे खूप भितीदायक आहे का? सर्वसाधारणपणे, मला माहित नाही की कोण "महासागर उकळणार आहे" आणि एका स्थानिक मशीनवर शेकडो हजारो किंवा अधिक उपकरणांचे तार्किक खंड तयार करणार आहे. जर कोणी मला हे समजावून सांगू शकले तर मी खूप आभारी राहीन. दरम्यान, माझ्यासाठी हे मार्केटिंग बल्शिट आहे.

कर्नल ब्लॉक उपकरण उपप्रणालीतील बदल (उदाहरणार्थ, blk-mq चे स्वरूप) FS अंमलबजावणीच्या आवश्यकतांवर कसा परिणाम करतात?

त्यांचा काहीही परिणाम झाला नाही. मला माहित नाही की ब्लॉक लेयरवर काय होईल ज्यामुळे नवीन FS डिझाइन करणे आवश्यक असेल. या उपप्रणालींचा परस्पर संवाद अतिशय खराब आहे. ड्रायव्हरच्या बाजूने, FS फक्त नवीन प्रकारच्या ड्राइव्हस्च्या देखाव्यामुळे प्रभावित व्हायला हवे, ज्यामध्ये प्रथम ब्लॉक लेयर समायोजित केले जाईल आणि नंतर FS (रीझर 4 साठी याचा अर्थ नवीन प्लगइनचा देखावा असेल).

नवीन प्रकारच्या माध्यमांचा उदय (उदाहरणार्थ, SMR, किंवा SSDs ची सर्वव्यापीता) याचा अर्थ फाइल सिस्टम डिझाइनसाठी मूलभूतपणे नवीन आव्हाने आहेत का?

होय. आणि हे एफएसच्या विकासासाठी सामान्य प्रोत्साहन आहेत. आव्हाने भिन्न आणि पूर्णपणे अनपेक्षित असू शकतात. उदाहरणार्थ, मी अशा ड्राइव्ह्सबद्दल ऐकले आहे जिथे I/O ऑपरेशनचा वेग डेटाच्या आकारावर आणि त्याच्या ऑफसेटवर अवलंबून असतो. लिनक्समध्ये, जेथे FS ब्लॉकचा आकार पृष्ठाच्या आकारापेक्षा जास्त असू शकत नाही, अशा ड्राइव्हची पूर्ण क्षमता डीफॉल्टनुसार दर्शविली जाणार नाही. तथापि, जर तुमची फाइल सिस्टम योग्यरित्या डिझाइन केली असेल, तर त्यातून बरेच काही मिळवण्याची संधी आहे.

तुमच्या व्यतिरिक्त किती लोक सध्या Reiser4 कोडवर काम करत आहेत?

मला पाहिजे त्यापेक्षा कमी, परंतु मला संसाधनांची तीव्र कमतरता देखील जाणवत नाही. मी Reiser4 च्या विकासाच्या गतीने अधिक समाधानी आहे. मी "घोडे चालवणार नाही" - हे योग्य क्षेत्र नाही. येथे, "जर तुम्ही अधिक शांतपणे गाडी चालवलीत तर तुम्ही चालत राहाल!" आधुनिक फाइल सिस्टम ही सर्वात जटिल कर्नल उपप्रणाली आहे, ज्याचे चुकीचे डिझाइन निर्णय मानवी कार्याच्या पुढील वर्षांना पूर्ववत करू शकतात.

स्वयंसेवकांना काहीतरी अंमलात आणण्यासाठी ऑफर करून, मी नेहमी हमी देतो की प्रयत्न नक्कीच योग्य परिणामाकडे नेतील, ज्याला गंभीर गरजांसाठी मागणी असू शकते. जसे तुम्ही समजता, अशा अनेक हमी एकाच वेळी असू शकत नाहीत. त्याच वेळी, मी "आकडे" उभे राहू शकत नाही जे स्पष्टपणे निरुपयोगी सॉफ्टवेअरच्या "वैशिष्ट्यांचा" निर्लज्जपणे प्रचार करतात, शेकडो वापरकर्ते आणि विकासकांना फसवतात आणि त्याच वेळी कर्नल शिखरांवर बसून हसतात.

कोणत्याही कंपनीने Reiser4 च्या विकासाला पाठिंबा देण्याची इच्छा व्यक्त केली आहे का?

होय, असे प्रस्ताव होते, समावेश. आणि मोठ्या विक्रेत्याकडून. पण यासाठी मला दुसऱ्या देशात जावे लागले. दुर्दैवाने, मी आता 30 वर्षांचा नाही, मी पहिल्या शीळ वाजल्यावर त्याप्रमाणे सोडून जाऊ शकत नाही.

Reiser4 मध्ये सध्या कोणती वैशिष्ट्ये गहाळ आहेत?

ReiserFS(v3) मध्ये आढळलेल्या सोप्या खंडांसाठी कोणतेही "आकार" फंक्शन नाही. याव्यतिरिक्त, DIRECT_IO ध्वजासह फाइल ऑपरेशन्स दुखापत होणार नाहीत. पुढे, मला एक व्हॉल्यूम “सिमेंटिक सबव्हॉल्यूम्स” मध्ये विभाजित करण्यास सक्षम व्हायचे आहे, ज्याचा आकार निश्चित नाही आणि जो स्वतंत्र व्हॉल्यूम म्हणून माउंट केला जाऊ शकतो. या समस्या नवशिक्यांसाठी चांगल्या आहेत ज्यांना "वास्तविक गोष्टी" मध्ये हात लावायचा आहे.

आणि शेवटी, मला साध्या अंमलबजावणी आणि प्रशासनासह नेटवर्क लॉजिकल व्हॉल्यूम हवे आहेत (आधुनिक अल्गोरिदम आधीपासूनच याची परवानगी देतात). पण RAID-Z, स्क्रब्स, फ्री स्पेस कॅशे, 4-बिट व्हेरिएबल्स आणि इतर मार्केटिंग बकवास जे काही फाइल सिस्टम्सच्या डेव्हलपर्समध्ये कल्पनांच्या कमतरतेच्या पार्श्वभूमीवर उद्भवलेले आहे ते Reiser128 मध्ये निश्चितपणे कधीही होणार नाही.

प्लगइनद्वारे आवश्यक असलेली प्रत्येक गोष्ट लागू केली जाऊ शकते का?

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

जर अंतिम वापरकर्त्याला असे "प्रतिस्थापन" लक्षात आले नाही, तर आम्ही म्हणतो की X इंटरफेसमध्ये सिस्टममध्ये शून्य-ऑर्डर पॉलिमॉर्फिझम आहे (किंवा X इंटरफेसमध्ये सिस्टम विषम आहे, जी समान गोष्ट आहे). जर आता तुमच्याकडे केवळ इंटरफेसचा संच नाही तर त्यावर संबंध देखील आहेत (इंटरफेस आलेख), तर तुम्ही उच्च ऑर्डरचे पॉलिमॉर्फिजम सादर करू शकता, जे कोणत्याही इंटरफेसच्या "शेजारी" मध्ये आधीपासूनच सिस्टमची विषमता दर्शवेल. मी बर्याच काळापूर्वी असे वर्गीकरण सादर केले होते, परंतु, दुर्दैवाने, असे कधीही झाले नाही.

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

आता मुख्य प्रश्नाकडे - Reiser4 च्या जाहिरातीसह गोष्टी मुख्य गाभ्यापर्यंत कशा जात आहेत? या फाइल सिस्टमच्या आर्किटेक्चरवर काही प्रकाशने होती का ज्याबद्दल तुम्ही शेवटच्या मुलाखतीत बोलला होता? तुमच्या दृष्टिकोनातून हा प्रश्न कितपत समर्पक आहे?

सर्वसाधारणपणे, आम्ही तीन वर्षांपासून मुख्य शाखेत समावेशासाठी विचारत आहोत. रिझरची सार्वजनिक थ्रेडमधील शेवटची टिप्पणी जिथे पुल विनंती केली गेली होती ती अनुत्तरित राहिली. त्यामुळे पुढील सर्व प्रश्न आमच्यासाठी नाहीत. मला वैयक्तिकरित्या समजत नाही की आम्हाला विशिष्ट ऑपरेटिंग सिस्टममध्ये "विलीन" करण्याची आवश्यकता का आहे. लिनक्सवर, प्रकाश एका वेजसारखा एकत्र येत नाही. तर, एक वेगळे भांडार आहे ज्यामध्ये वेगवेगळ्या OS साठी अनेक शाखा-पोर्ट असतील. ज्याला त्याची गरज आहे तो संबंधित पोर्ट क्लोन करू शकतो आणि त्याच्यासह आपल्याला पाहिजे ते करू शकतो (अर्थातच परवान्यामध्ये). बरं, जर एखाद्याला त्याची गरज नसेल, तर ती माझी समस्या नाही. या टप्प्यावर, मी “मुख्य लिनक्स कर्नलमध्ये पदोन्नती” या प्रश्नावर विचार करण्याचा प्रस्ताव ठेवतो.

FS आर्किटेक्चरवरील प्रकाशने प्रासंगिक आहेत, परंतु आतापर्यंत मला माझ्या नवीन निकालांसाठी फक्त वेळ मिळाला आहे, ज्याला मी उच्च प्राधान्य मानतो. दुसरी गोष्ट अशी आहे की मी एक गणितज्ञ आहे आणि गणितात कोणतेही प्रकाशन हे प्रमेय आणि त्यांचे पुरावे यांचा सारांश आहे. पुराव्याशिवाय तेथे काहीही प्रकाशित करणे हे वाईट चवीचे लक्षण आहे. जर मी FS च्या आर्किटेक्चरबद्दल कोणतेही विधान पूर्णपणे सिद्ध केले किंवा नाकारले तर त्याचा परिणाम असा होईल की त्यातून जाणे खूप कठीण होईल. कोणाला त्याची गरज आहे? म्हणूनच कदाचित सर्व काही त्याच्या जुन्या स्वरूपातच राहते - स्त्रोत कोड आणि त्यावर टिप्पण्या.

गेल्या काही वर्षांत Reiser4 मध्ये नवीन काय आहे?

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

आम्ही शेवटी आमची दीर्घकालीन कल्पना - भिन्न व्यवहार मॉडेल्स अंमलात आणण्यात यशस्वी झालो. पूर्वी, Reiser4 फक्त एक हार्डकोड केलेले Macdonald-Reiser मॉडेल चालवत होते. यामुळे डिझाइन समस्या निर्माण झाल्या. विशेषतः, अशा व्यवहार मॉडेलमध्ये स्नॅपशॉट शक्य नाहीत - ते "ओव्हरराईट सेट" नावाच्या अणू घटकाद्वारे खराब केले जातील. Reiser4 सध्या तीन व्यवहार मॉडेलला समर्थन देते. त्यापैकी एकामध्ये (कोठेही लिहा), अणू घटक ओव्हरराईट सेटमध्ये फक्त सिस्टम पृष्ठे (डिस्क बिटमॅपच्या प्रतिमा इ.) समाविष्ट आहेत, ज्याचे "छायाचित्र" (चिकन आणि अंडी समस्या) असू शकत नाहीत.

त्यामुळे चित्रे आता शक्य तितक्या चांगल्या पद्धतीने साकारता येतील. दुसऱ्या व्यवहाराच्या मॉडेलमध्ये, सर्व सुधारित पृष्ठे फक्त ओव्हरराईट सेटवर जातात (म्हणजेच, हे मूलत: शुद्ध जर्नलिंग आहे). हे मॉडेल त्यांच्यासाठी आहे ज्यांनी Reiser4 विभाजनांच्या जलद विखंडनबद्दल तक्रार केली आहे. आता या मॉडेलमध्ये तुमचे विभाजन ReiserFS (v3) पेक्षा वेगाने खंडित होणार नाही. सर्व तीन विद्यमान मॉडेल्स, काही आरक्षणांसह, ऑपरेशन्सच्या अणुत्वाची हमी देतात, परंतु अणुत्व कमी करणारे आणि केवळ विभागाची अखंडता जपणारे मॉडेल देखील उपयुक्त ठरू शकतात. अशी मॉडेल्स सर्व प्रकारच्या ऍप्लिकेशन्ससाठी (डेटाबेस, इ.) उपयुक्त असू शकतात, ज्यांनी यापैकी काही फंक्शन्स आधीच घेतली आहेत. हे मॉडेल Reiser4 मध्ये जोडणे खूप सोपे आहे, परंतु मी ते केले नाही, कारण मला कोणीही विचारले नाही आणि मला वैयक्तिकरित्या याची आवश्यकता नाही.

मेटाडेटा चेकसम दिसू लागले आणि मी नुकतेच त्यांना "किफायतशीर" मिरर (अद्याप अस्थिर सामग्री) सह पूरक केले. कोणत्याही ब्लॉकचा चेकसम अयशस्वी झाल्यास, Reiser4 त्वरित प्रतिकृती उपकरणावरून संबंधित ब्लॉक वाचते. लक्षात ठेवा की ZFS आणि Btrf हे करू शकत नाहीत: डिझाइन त्यास परवानगी देत ​​नाही. तेथे तुम्हाला "स्क्रब" नावाची विशेष पार्श्वभूमी स्कॅनिंग प्रक्रिया चालवणे आवश्यक आहे आणि समस्याप्रधान ब्लॉकवर जाण्यासाठी प्रतीक्षा करावी लागेल. प्रोग्रामर अशा घटनांना लाक्षणिक अर्थाने "क्रचेस" म्हणतात.

आणि शेवटी, विषम लॉजिकल व्हॉल्यूम दिसू लागले आहेत, जे ZFS, Btrfs, ब्लॉक लेयर, तसेच FS+LVM कॉम्बिनेशन तत्त्वत: प्रदान करू शकत नाहीत - समांतर स्केलिंग, O(1) डिस्क ॲड्रेस ऍलोकेटर, सबव्हॉल्यूममधील पारदर्शक डेटा माइग्रेशन. नंतरचा वापरकर्ता इंटरफेस देखील आहे. आता तुम्ही सर्वात लोकप्रिय डेटा तुमच्या व्हॉल्यूमवरील सर्वोच्च-कार्यक्षमता ड्राइव्हवर सहजपणे हलवू शकता.

याव्यतिरिक्त, अशा ड्राइव्हवर कोणतीही घाणेरडी पृष्ठे तातडीने फ्लश करणे शक्य आहे, ज्यामुळे अनेकदा fsync(2) कॉल करणाऱ्या अनुप्रयोगांना लक्षणीयरीत्या गती मिळते. मी लक्षात घेतो की ब्लॉक लेयर कार्यक्षमता, ज्याला bcache म्हणतात, अशा कृतीचे स्वातंत्र्य अजिबात प्रदान करत नाही. नवीन लॉजिकल व्हॉल्यूम माझ्या अल्गोरिदमवर आधारित आहेत (तिथे संबंधित पेटंट आहेत). सॉफ्टवेअर आधीच खूप स्थिर आहे, ते वापरून पाहणे, कार्यप्रदर्शन मोजणे इ. फक्त गैरसोय अशी आहे की आत्ता तुम्हाला व्हॉल्यूम कॉन्फिगरेशन व्यक्तिचलितपणे अद्यतनित करणे आणि ते कुठेतरी संग्रहित करणे आवश्यक आहे.

आतापर्यंत मी माझ्या कल्पना 10 टक्क्यांनी अंमलात आणू शकलो आहे, तथापि, मी सर्वात कठीण गोष्ट मानली आहे - तार्किक खंडांना फ्लॅश प्रक्रियेसह जोडणे जे रीझर 4 मध्ये सर्व स्थगित क्रिया करते. हे सर्व अजूनही प्रायोगिक "स्वरूप 41" शाखेत आहे.

Reiser4 xfstests पास करतो का?

जेव्हा मी शेवटचा रिलीज तयार करत होतो तेव्हा किमान माझ्यासाठी ते झाले.

प्लगइन वापरून Reiser4 नेटवर्क (क्लस्टर) FS बनवणे तत्त्वतः शक्य आहे का?

हे शक्य आहे, आणि अगदी आवश्यक आहे! आपण योग्यरित्या डिझाइन केलेल्या स्थानिक फाइल सिस्टमवर आधारित नेटवर्क फाइल तयार केल्यास, परिणाम खूप प्रभावी असेल! आधुनिक नेटवर्क FS मध्ये, मी बॅकएंड स्टोरेज पातळीच्या उपस्थितीबद्दल समाधानी नाही, जे कोणत्याही स्थानिक FS वापरून लागू केले जाते. या पातळीचे अस्तित्व पूर्णपणे अन्यायकारक आहे. नेटवर्क FS ने ब्लॉक लेयरशी थेट संवाद साधला पाहिजे आणि स्थानिक FS ला इतर सेवा फाइल्स तयार करण्यास सांगू नये!

सर्वसाधारणपणे, फाईल सिस्टीमचे स्थानिक आणि नेटवर्कमध्ये विभाजन करणे वाईट आहे. तीस वर्षांपूर्वी वापरल्या गेलेल्या अल्गोरिदमच्या अपूर्णतेपासून ते उद्भवले आणि त्याऐवजी अद्याप काहीही प्रस्तावित केलेले नाही. अनावश्यक सॉफ्टवेअर घटक (विविध सेवा इ.) दिसण्याचे हे देखील कारण आहे. चांगल्या प्रकारे, कर्नल मॉड्यूलच्या रूपात फक्त एक FS आणि प्रत्येक मशीनवर स्थापित वापरकर्त्याच्या उपयुक्ततेचा संच असावा - क्लस्टर नोड. हे FS स्थानिक आणि नेटवर्क दोन्ही आहे. आणि आणखी काही नाही!

लिनक्सवर Reiser4 सोबत काहीही जमले नाही तर, मी FreeBSD साठी FS ऑफर करू इच्छितो (मागील मुलाखतीचा कोट: “...FreeBSD... शैक्षणिक मुळे आहेत... आणि याचा अर्थ असा की आम्ही उच्च संभाव्यतेसह विकसकांसह एक सामान्य भाषा सापडेल")?

तर, आम्हाला आत्ताच कळल्याप्रमाणे, Linux सह सर्व काही आधीच पूर्ण झाले आहे: आमच्या रेपॉजिटरीच्या मास्टर ब्रँचच्या स्वरूपात त्यासाठी वेगळे कार्यरत Reiser4 पोर्ट आहे. मी फ्रीबीएसडी बद्दल विसरलो नाही! ऑफर! ज्यांना FreeBSD चा अंतर्भाव चांगला ठाऊक आहे त्यांच्याशी मी जवळून काम करण्यास तयार आहे. तसे: मला त्यांच्या समुदायाबद्दल खरोखर काय आवडते ते म्हणजे स्वतंत्र तज्ञांच्या अद्ययावत परिषदेद्वारे निर्णय घेतले जातात, ज्याचा एका कायमस्वरूपी व्यक्तीच्या सरकारी फसवणुकीशी काहीही संबंध नाही.

आज तुम्ही लिनक्स वापरकर्ता समुदायाला कसे रेट करता? ते अधिक "पॉप" झाले आहे का?

माझ्या कामाचे स्वरूप पाहता, याचे आकलन करणे माझ्यासाठी खूप कठीण आहे. बहुतेक वापरकर्ते माझ्याकडे बग अहवाल आणि विभागाचे निराकरण करण्याच्या विनंत्या घेऊन येतात. वापरकर्ते म्हणून वापरकर्ते. काही अधिक जाणकार, काही कमी. सर्वांना समान वागणूक दिली जाते. बरं, जर वापरकर्त्याने माझ्या सूचनांकडे दुर्लक्ष केले, तर मला माफ करा: दुर्लक्ष करण्याचा आदेश माझ्याकडून देखील प्रविष्ट केला जाईल.

पुढील पाच ते दहा वर्षे फाईल सिस्टीमच्या विकासाचा अंदाज बांधणे शक्य आहे का? FS विकासकांना तोंड द्यावे लागणारी मुख्य आव्हाने कोणती आहेत असे तुम्हाला वाटते?

होय, असा अंदाज बांधणे अवघड नाही. बर्याच काळापासून अपस्ट्रीममध्ये फाइल सिस्टमचा विकास झालेला नाही. असा केवळ देखावा तयार होतो. स्थानिक फाइल सिस्टमचे विकसक खराब डिझाइनशी संबंधित समस्यांना सामोरे गेले. येथे सावधगिरी बाळगणे आवश्यक आहे. मी तथाकथित “स्टोरेज”, “चाटणे” आणि कोड ऑफ पोर्टिंगला विकास आणि विकास मानत नाही. आणि मी आधीच स्पष्ट केलेल्या कारणांसाठी "Btrfs" नावाच्या गैरसमजाचे विकास म्हणून वर्गीकरण करत नाही.

प्रत्येक पॅच फक्त त्याच्या समस्या वाढवतो. विहीर. आणि नेहमीच विविध प्रकारचे "सुवार्तिक" असतात ज्यांच्यासाठी "सर्व काही कार्य करते." मुळात ही शाळकरी मुलं आणि लेक्चर्स वगळणारे विद्यार्थी आहेत. फक्त कल्पना करा: हे त्याच्यासाठी कार्य करते, परंतु प्राध्यापक तसे करत नाही. ही किती एड्रेनालाईन गर्दी आहे! माझ्या दृष्टीकोनातून, सर्वात जास्त नुकसान "कारागीर" मुळे होते ज्यांनी Btrfs ची अद्भुत वैशिष्ट्ये systemd, docker इत्यादी सर्व प्रकारच्या स्तरांवर उत्साहाने "स्क्रू" केली. - हे आधीच मेटास्टेसेससारखे दिसते.

आता पाच ते दहा वर्षांचा अंदाज बांधण्याचा प्रयत्न करूया. आम्ही Reiser4 मध्ये काय करणार आहोत ते मी आधीच थोडक्यात सूचीबद्ध केले आहे. अपस्ट्रीममधील स्थानिक FS डेव्हलपर्ससाठी मुख्य आव्हान असेल (होय, ते आधीच झाले आहे) पगारासाठी योग्य नोकरी करण्यास असमर्थता. डेटा स्टोरेजच्या क्षेत्रात कोणतीही कल्पना न ठेवता, ते या दुर्दैवी VFS, XFS आणि ext4 ला पॅच करण्याचा प्रयत्न करत राहतील. या पार्श्वभूमीवर VFS ची परिस्थिती विशेषत: हास्यास्पद दिसते, जे एका रेस्टॉरंटच्या उन्मादपूर्ण आधुनिकीकरणाची आठवण करून देते ज्यामध्ये शेफ नसतात आणि शेफची अपेक्षा नसते.

आता VFS कोड, कोणत्याही अटींशिवाय, एकाच वेळी अनेक मेमरी पृष्ठे लॉक करतो आणि अंतर्निहित FS ला त्यांच्यावर कार्य करण्यासाठी आमंत्रित करतो. डिलीट ऑपरेशन्सवर Ext4 चे कार्यप्रदर्शन सुधारण्यासाठी हे सादर केले गेले, परंतु समजण्यास सोपे आहे, असे समवर्ती लॉकिंग प्रगत व्यवहार मॉडेल्सशी पूर्णपणे विसंगत आहे. म्हणजेच, तुम्ही कर्नलमधील काही स्मार्ट फाइल सिस्टमसाठी फक्त समर्थन जोडू शकणार नाही. लिनक्सच्या इतर भागात काय परिस्थिती आहे हे मला माहीत नाही, पण फाइल सिस्टीमचा संबंध आहे, इथला कोणताही विकास टॉरवाल्ड्सने व्यवहारात राबवलेल्या धोरणाशी सुसंगत असण्याची शक्यता नाही (शैक्षणिक प्रकल्प बाहेर काढले जातात आणि घोटाळे करणारे बी-ट्री, विश्वासाचे अंतहीन क्रेडिट्स जारी केले जातात याची कल्पना नाही). म्हणून, हळूहळू क्षय करण्यासाठी एक कोर्स सेट केला गेला. अर्थात, ते "विकास" म्हणून पुढे जाण्याचा सर्वतोपरी प्रयत्न करतील.

पुढे, फाइल सिस्टमचे “कस्टोडियन”, आपण एकट्या “स्टोरेज” मधून जास्त कमाई करू शकत नाही हे लक्षात घेऊन, अधिक फायदेशीर व्यवसायात त्यांचा हात आजमावतील. हे, एक नियम म्हणून, वितरित फाइल सिस्टम आणि आभासीकरण आहेत. कदाचित ते फॅशनेबल ZFS कुठेतरी पोर्ट करतील जिथे ते अद्याप अस्तित्वात नाही. परंतु, ते, अपस्ट्रीमच्या सर्व एफएसप्रमाणे, नवीन वर्षाच्या झाडासारखे दिसते: जर तुम्ही इतर काही लहान गोष्टी शीर्षस्थानी ठेवू शकता, तर तुम्ही आणखी खोलवर जाऊ शकत नाही. मी कबूल करतो की ZFS वर आधारित एक गंभीर एंटरप्राइझ सिस्टम तयार करणे शक्य आहे, परंतु आम्ही आता भविष्याबद्दल चर्चा करत असल्याने, मी फक्त दुःखाने सांगू शकतो की ZFS या संदर्भात निराश आहे: त्यांच्या आभासी उपकरणांसह, मुलांनी ऑक्सिजन कापला आहे. पुढील विकासासाठी स्वतःसाठी आणि भावी पिढ्यांसाठी. ZFS ही भूतकाळातील गोष्ट आहे. आणि ext4 आणि XFS कालच्या आदल्या दिवशीही नाहीत.

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

फाइल सिस्टम यासाठी योग्य आहेत, कारण तुम्ही निकालावर दहा वर्षांसाठी सुरक्षितपणे सौदा करू शकता. बरं, जर एखाद्याने नंतर या निकालाच्या कमतरतेबद्दल तक्रार केली तर त्याला फाइल सिस्टमबद्दल काहीही समजत नाही! हे आर्थिक पिरॅमिडची आठवण करून देणारे आहे: शीर्षस्थानी साहसी आहेत ज्यांनी हा गोंधळ सुरू केला आणि ते काही "भाग्यवान" होते: त्यांनी "लाभांश काढून घेतला," म्हणजे. विकासासाठी पैसे मिळाले, व्यवस्थापक म्हणून चांगल्या पगाराची नोकरी मिळाली, परिषदांमध्ये "दाखवले" इ.

पुढे ते येतात जे “अशुभ” आहेत: ते नुकसान मोजतील, निरुपयोगी सॉफ्टवेअर उत्पादन उत्पादनात उपयोजित केल्यावर होणाऱ्या परिणामांना सामोरे जातील, “इ. त्यापैकी बरेच आहेत. बरं, पिरॅमिडच्या पायथ्याशी निरुपयोगी कोड "सॉइंग" करणाऱ्या विकसकांचा एक मोठा समूह आहे. ते सर्वात मोठे नुकसान करणारे आहेत, कारण वाया गेलेला वेळ परत करता येत नाही. टोरवाल्ड्स आणि त्याच्या सहकाऱ्यांसाठी असे पिरॅमिड्स अत्यंत फायदेशीर आहेत. आणि या पिरॅमिड्सपैकी अधिक, त्यांच्यासाठी चांगले. अशा पिरॅमिडला खायला देण्यासाठी, काहीही कोरमध्ये घेतले जाऊ शकते. अर्थात, सार्वजनिकपणे ते उलट म्हणतात. पण मी शब्दांनी नाही तर कृतीने न्याय करतो.

तर, “लिनक्समधील फाईल सिस्टीमचे भविष्य” हे आणखी एक अत्यंत प्रमोट केलेले, परंतु वापरता येण्याजोगे सॉफ्टवेअर आहे. Btrfs नंतर, उच्च संभाव्यतेसह, अशा "भविष्य" ची जागा Bcachefs द्वारे घेतली जाईल, जी फाइल सिस्टमसह लिनक्स ब्लॉक लेयर ओलांडण्याचा आणखी एक प्रयत्न आहे (एक वाईट उदाहरण संसर्गजन्य आहे). आणि वैशिष्ट्यपूर्ण काय आहे: Btrfs प्रमाणेच समस्या आहेत. मला याचा बराच काळ संशय आला, आणि मग कसा तरी मी प्रतिकार करू शकलो नाही आणि कोडकडे पाहिले - हे खरे आहे!

Bcachefs आणि Btrfs च्या लेखकांनी, त्यांचे FS तयार करताना, सक्रियपणे इतर लोकांच्या स्त्रोतांचा वापर केला, त्यांच्याबद्दल थोडेसे समजले. परिस्थिती मुलांच्या खेळ "तुटलेली फोन" ची खूप आठवण करून देते. आणि हा कोड कर्नलमध्ये कसा समाविष्ट केला जाईल याची मी अंदाजे कल्पना करू शकतो. वास्तविक, कोणीही “रेक” पाहणार नाही (प्रत्येकजण नंतर त्यावर पाऊल टाकेल). कोडच्या शैलीबद्दल, अस्तित्वात नसलेल्या उल्लंघनांचे आरोप इत्यादींबद्दल असंख्य प्रश्नांनंतर, लेखकाच्या "निष्ठा" बद्दल, तो इतर विकसकांशी किती चांगला "संवाद" करतो आणि हे सर्व किती यशस्वीपणे करू शकते याबद्दल एक निष्कर्ष काढला जाईल. नंतर कॉर्पोरेशनला विकले जाईल.

अंतिम परिणाम कोणालाही रुचणार नाही. वीस वर्षांपूर्वी, कदाचित, मला स्वारस्य वाटले असते, परंतु आता प्रश्न वेगळ्या पद्धतीने विचारले जात आहेत: पुढील दहा वर्षांत काही विशिष्ट लोकांना रोजगार मिळावा म्हणून याचा प्रचार करणे शक्य होईल का? आणि, अरेरे, अंतिम परिणामाबद्दल आश्चर्य करण्याची प्रथा नाही.

सर्वसाधारणपणे, तुमची फाइल सिस्टीम सुरवातीपासून पुन्हा शोधणे सुरू करण्याविरुद्ध मी जोरदार सल्ला देईन. कारण दहा वर्षांत स्पर्धात्मक काहीतरी मिळवण्यासाठी महत्त्वाची आर्थिक गुंतवणूकही पुरेशी होणार नाही. अर्थात, मी गंभीर प्रकल्पांबद्दल बोलत आहे, आणि कर्नलमध्ये "पुश" करण्याच्या उद्देशाने नाही. म्हणून, स्वतःला अभिव्यक्त करण्याचा अधिक प्रभावी मार्ग म्हणजे आमच्यासारख्या वास्तविक घडामोडींमध्ये सामील होणे. हे, अर्थातच, करणे सोपे नाही - परंतु हे कोणत्याही उच्च-स्तरीय प्रकल्पाच्या बाबतीत आहे.

प्रथम, मी ऑफर करत असलेल्या समस्येवर स्वतंत्रपणे मात करणे आवश्यक आहे. त्यानंतर, तुमच्या हेतूंचे गांभीर्य लक्षात घेऊन, मी मदत करण्यास सुरवात करेन. पारंपारिकपणे, आम्ही फक्त आमच्या स्वतःच्या विकासाचा वापर करतो. अपवाद म्हणजे कॉम्प्रेशन अल्गोरिदम आणि काही हॅश फंक्शन्स. आम्ही विकासकांना परिषदांमध्ये प्रवास करण्यासाठी पाठवत नाही आणि नंतर आम्ही बसून इतर लोकांच्या कल्पना एकत्र करत नाही ("कदाचित काय होईल"), जसे की बहुतेक स्टार्टअपमध्ये प्रथा आहे.

आम्ही सर्व अल्गोरिदम स्वतः विकसित करतो. मला सध्या डेटा स्टोरेज सायन्सच्या बीजगणितीय आणि एकत्रित पैलूंमध्ये रस आहे. विशेषतः, मर्यादित फील्ड, एसिम्प्टोटिक्स, असमानतेचा पुरावा. सामान्य प्रोग्रामरसाठी देखील कार्य आहे, परंतु मी तुम्हाला ताबडतोब चेतावणी दिली पाहिजे: "दुसरा एफएस पहा आणि तेच करा" या सर्व सूचना दुर्लक्षित केल्या आहेत. VFS द्वारे Linux सह जवळचे एकत्रीकरण करण्याच्या उद्देशाने पॅचेस देखील तेथे जातील.

म्हणून, आमच्याकडे रेक नाही, परंतु आम्हाला कुठे हलवायचे आहे याची आम्हाला समज आहे आणि आम्हाला खात्री आहे की ही दिशा योग्य आहे. ही समज स्वर्गातून मान्नाच्या स्वरूपात आली नाही. मी तुम्हाला आठवण करून देतो की आमच्या मागे 29 वर्षांचा विकास अनुभव आहे, दोन फाइल सिस्टीम सुरवातीपासून लिहिलेल्या आहेत. आणि डेटा पुनर्प्राप्ती उपयुक्ततांची समान संख्या. आणि हे खूप आहे!

स्त्रोत: opennet.ru