फ़ाइल सिस्टम को पढ़ना सीखना

इस लेख में क्या होगा?

हम अकादमिक विश्वविद्यालय में ओएस कोर्स की सामग्री के आधार पर लिनक्स कर्नेल में एक फ़ाइल सिस्टम बनाने पर लेखों की श्रृंखला जारी रखते हैं।



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



इस लेख का मुख्य लक्ष्य डिस्क से पढ़ने के लिए फ़ाइल सिस्टम को पढ़ाना है। अब तक, वह केवल सेवा की जानकारी (सुपरब्लॉक और इंडेक्स नोड्स) पढ़ेगी, इसलिए इसका उपयोग करना अभी भी काफी कठिन है।



इतना कम क्यों? तथ्य यह है कि इस पोस्ट में हमें अपनी फाइल सिस्टम की संरचना निर्धारित करने की आवश्यकता होगी - यह डिस्क पर कैसे संग्रहीत किया जाएगा। इसके अलावा, हम कुछ दिलचस्प बिंदुओं का सामना करेंगे, जैसे कि SLAB और RCU। यह सब कुछ स्पष्टीकरण की आवश्यकता होगी - बहुत सारे शब्द और थोड़ा कोड, इसलिए पोस्ट पहले से ही बहुत अधिक चमकदार होगी।

बोरिंग शुरू

हमारी फ़ाइल प्रणाली सरल होनी चाहिए, इसलिए इसे डिस्क पर ही संग्रहीत किया जाएगा:







चलो अंत से शुरू करते हैं:

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

वास्तव में समान डिस्क लेआउट का उपयोग अन्य फाइल सिस्टम में किया जाता है। उदाहरण के लिए, ext2 / 3 में ब्लॉक का एक समूह एक समान संरचना है, केवल ext2 / 3 ऐसे कई समूहों के साथ काम करता है, और हम खुद को एक तक सीमित कर लेंगे। यह प्रारूप अप्रचलित माना जाता है, और नई फ़ाइल प्रणालियाँ इससे दूर जा रही हैं। उदाहरण के लिए, btrfs एक अधिक दिलचस्प योजना का उपयोग करता है जो अतिरिक्त परिवार पर कई लाभ प्रदान करता है। लेकिन हमारी भेड़ों को वापस ले आओ।



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



Mke2fs उपयोगिता, जिसका उपयोग ext2 / 3 फ़ाइल सिस्टम के लिए डिस्क को प्रारूपित करने के लिए किया जाता है, में -i स्विच होता है , जो यह दर्शाता है कि इंडेक्स नोड बनाने के लिए कितना डिस्क स्थान है, अर्थात यदि आप -38 1638 निर्दिष्ट करते हैं, तो डिस्क स्थान के प्रत्येक 16obytes के लिए होगा इंडेक्स नोड द्वारा बनाया गया। मैं सबसे सरल विकल्प का उपयोग करूंगा - मैं इस मूल्य को बदलने की संभावना के बिना डिस्क स्थान के प्रत्येक 16 Kb के लिए एक सूचकांक नोड बनाऊंगा (अब कम से कम)।



उल्लेख के लायक अंतिम सामान्य बिंदु ब्लॉक आकार है। फ़ाइल सिस्टम विभिन्न आकारों के ब्लॉक के साथ काम कर सकता है, मैं 512, 1024, 2048 और 4096 बाइट्स के ब्लॉकों का समर्थन करूंगा - असामान्य कुछ भी नहीं। यह इस तथ्य के कारण है कि पृष्ठ में फिट होने वाले ब्लॉकों के साथ काम करना आसान है (हम इस पर बाद में लौटेंगे), लेकिन यह बिल्कुल भी आवश्यक नहीं है, इसके अलावा, बड़े ब्लॉक आकार अधिक से अधिक प्रदर्शन में योगदान कर सकते हैं।



सामान्य तौर पर, क्लासिक फ़ाइल सिस्टम के लिए सही ब्लॉक आकार चुनना एक बहुत ही दिलचस्प विषय है। उदाहरण के लिए, ओएस पर एक प्रसिद्ध पुस्तक में , जानकारी दी गई है कि 4 केबी के ब्लॉक आकार के साथ, 60 - 70% फाइलें एक ब्लॉक में रखी जाएंगी। अधिक फाइलें एक ब्लॉक में फिट होती हैं, कम विखंडन, उच्च पढ़ने की गति, लेकिन अधिक स्थान भी बर्बाद होता है। हमारे मामले में, अन्य बातों के अलावा, ब्लॉक आकार फ़ाइल सिस्टम का मुख्य सीमक है - 4 केबी के ब्लॉक आकार के साथ, मुफ्त ब्लॉक का एक बिटमैप केवल 128 एमबी डिस्क स्थान को कवर कर सकता है।

वापस अभ्यास करने के लिए

यह कुछ कोड लिखने का समय है। आइए हम उन संरचनाओं से शुरू करें जिनका हम उपयोग करेंगे, सबसे सरल से शुरू करते हैं:

struct aufs_disk_super_block { __be32 dsb_magic; __be32 dsb_block_size; __be32 dsb_root_inode; __be32 dsb_inode_blocks; };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

सुपर ब्लॉक संरचना 0 ब्लॉक डिस्क की शुरुआत में संग्रहीत है। यह एक जादू की संख्या के साथ शुरू होता है, इसके अनुसार हम यह सुनिश्चित कर सकते हैं कि aufs डिस्क पर संग्रहीत है (मैंने पिछली बार इसका उल्लेख किया था)।



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



इसके अलावा, सूचकांक नोड्स की तालिका में ब्लॉक की संख्या dsb_inode_blocks फ़ील्ड में संग्रहीत की जाती है - मैंने पहले ही उल्लेख किया था कि इस तालिका का आकार अलग हो सकता है।



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



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



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



__Be32 प्रकार, वास्तव में, uint32_t का एक पर्याय है, लेकिन इसका नाम इस बात पर जोर देता है कि चर बड़े एंडियन (एक तरह की प्रलेखन विधि) में डेटा संग्रहीत करता है। थोड़ा एंडियन के लिए कर्नेल में एक समान प्रकार है।



अब फाइल सिस्टम की सबसे महत्वपूर्ण संरचना को देखते हैं - इंडेक्स नोड:

 struct aufs_disk_inode { __be32 di_first; __be32 di_blocks; __be32 di_size; __be32 di_gid; __be32 di_uid; __be32 di_mode; __be64 di_ctime; };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

सूचकांक नोड मुख्य रूप से यह निर्धारित करता है कि डिस्क पर फ़ाइल / निर्देशिका कहाँ संग्रहीत है। फ़ाइलों को संग्रहीत करने के तरीके बहुत विविध हो सकते हैं, मैं प्रति फ़ाइल एक काफी सरल एक सीमा का उपयोग करूंगा। एक्स्टेंट - डिस्क ब्लॉक का एक निरंतर अनुक्रम, अर्थात, प्रत्येक फ़ाइल / निर्देशिका को ब्लॉकों के एक सतत अनुक्रम में संग्रहीत किया जाएगा। Di_first और di_blocks फ़ील्ड क्रमशः पहले ब्लॉक और ब्लॉक की संख्या को स्टोर करते हैं।



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



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



यह स्पष्ट है कि extents एक मुश्किल संरचना नहीं है और कम प्रदान करते हैं, लेकिन डिस्क पर फ़ाइलों को संग्रहीत करने के लिए क्लासिक ट्री संरचनाओं के साथ, वे खंडित फ़ाइल सिस्टम के लिए भी एक अच्छा विकल्प बनते हैं।



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



Di_gid और di_uid फ़ील्ड समूह और उपयोगकर्ता के पहचानकर्ता हैं। फ़ाइल सिस्टम में इस तरह की जानकारी को बचाने के लिए इसका कोई मतलब नहीं है; मैंने उन्हें एक उदाहरण के रूप में डाला।



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



अंत में, di_ctime फ़ील्ड उस तारीख को रखती है जब फ़ाइल बनाई गई थी। आमतौर पर फ़ाइल सिस्टम अंतिम संशोधन और फ़ाइल तक पहुंचने की तारीखों के निर्माण के साथ-साथ स्टोर करते हैं, लेकिन हम उन पर हथौड़ा मारेंगे।

प्रारूप डिस्क

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



लिनक्स कर्नेल के बारे में एक लेख को C ++ (विशेष रूप से बाद के लिए लिनुस के रवैये के प्रकाश में) के बारे में लेख को चालू न करने के लिए, मेरा सुझाव है कि आप स्रोतों के साथ खुद से निपटें, लेकिन संक्षेप में मुख्य कक्षाओं से गुजरें:

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

उपयोगिता आपको -s या --block_size कुंजियों के माध्यम से ब्लॉक आकार को बदलने की अनुमति देती है, और ब्लॉक की संख्या जो फ़ाइल सिस्टम के लिए -b या --blocks कुंजी के माध्यम से उपयोग की जाएगी।



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

फाइल सिस्टम पर वापस

अब हमारे डाउनलोड करने योग्य मॉड्यूल पर वापस जाएं। हम डिस्क से सुपरब्लॉक पढ़कर शुरू करते हैं। लेकिन इससे पहले, चलो सुपरब्लॉक के लिए एक और संरचना प्राप्त करें:

 struct aufs_super_block { uint32_t asb_magic; uint32_t asb_inode_blocks; uint32_t asb_block_size; uint32_t asb_root_inode; uint32_t asb_inodes_in_block; };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

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



अंतिम पोस्ट को याद करते हुए, हमारे पास पहले से ही सुपरब्लॉक का प्रतिनिधित्व करने के लिए तीन संरचनाएं हैं:

• सुपर_ब्लॉक - वह संरचना जो कर्नेल प्रदान करती है;
• aufs_disk_super_block - एक संरचना जो डिस्क पर संग्रहीत होती है;
• aufs_super_block एक और संरचना है जिसे मेमोरी में संग्रहीत किया जाएगा;

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



कर्नेल में, इस तरह के रिश्ते को व्यवस्थित करने के दो सामान्य तरीके हैं (चलो उन्हें रचना और विरासत कहते हैं)। सुपर ब्लॉक के लिए, हम रचना का उपयोग करेंगे। इस विधि को कर्नेल से समर्थन की आवश्यकता होती है - सुपर_ब्लॉक संरचना के अंदर एक दिलचस्प क्षेत्र है:

 struct super_block { ... void *s_fs_info; ... };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

इस क्षेत्र में हम किसी भी डेटा के लिए एक पॉइंटर को बचा सकते हैं, वास्तव में, वहाँ हम एक पॉइंटर को aufs_super_block को सेव करेंगे। और जहाँ भी हमारे पास super_block संरचना है, हम aufs_super_block संरचना तक भी पहुँच सकते हैं। लेकिन हाँ यह सभी गीत हैं, हमारा काम डिस्क से सुपरब्लॉक पढ़ना है। ऐसा करने के लिए, हम कुछ फ़ंक्शन लिखेंगे:

 static struct aufs_super_block *aufs_super_block_read(struct super_block *sb) { struct aufs_super_block *asb = (struct aufs_super_block *)kzalloc(sizeof(struct aufs_super_block), GFP_NOFS); struct aufs_disk_super_block *dsb = NULL; struct buffer_head *bh = NULL; if (!asb) { pr_err("aufs cannot allocate super block\n"); return NULL; } bh = sb_bread(sb, 0); if (!bh) { pr_err("cannot read 0 block\n"); goto free_memory; } dsb = (struct aufs_disk_super_block *)bh->b_data; aufs_super_block_fill(asb, dsb); brelse(bh); if (asb->asb_magic != AUFS_MAGIC) { pr_err("wrong magic number %u\n", (unsigned)asb->asb_magic); goto free_memory; } return asb; free_memory: kfree(asb); return NULL; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

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



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



स्वाभाविक रूप से, हम कर्नेल में जांचना नहीं भूलते हैं कि मेमोरी समस्याओं के बिना आवंटित की गई थी।



अगला सिद्धांत बिंदु sb_bread फ़ंक्शन का कॉल है। यहाँ यह डिस्क से पढ़ रहा है! यह फ़ंक्शन सुपरब्लॉक और ब्लॉक नंबर को पढ़ने के लिए एक पॉइंटर स्वीकार करता है - काफी सरल। फ़ंक्शन बफर_हेड संरचना के लिए एक संकेतक लौटाता है, और ब्लॉक डेटा स्वयं इस संरचना के b_data फ़ील्ड के माध्यम से पहुंच योग्य है।



स्वाभाविक रूप से, इस मामले में, यह जांचना न भूलें कि पढ़ना सफल था।



इसके बाद, हम पॉइंटर को चार्ट में बदलकर पॉइंटर को aufs_disk_super_block संरचना में बदल देते हैं। Aufs_super_block_fill फ़ंक्शन aufs_super_block संरचना को कुछ भी असामान्य किए बिना aufs_disk_super_block का उपयोग करके भरता है:

 static inline void aufs_super_block_fill(struct aufs_super_block *asb, struct aufs_disk_super_block const *dsb) { asb->asb_magic = be32_to_cpu(dsb->dsb_magic); asb->asb_inode_blocks = be32_to_cpu(dsb->dsb_inode_blocks); asb->asb_block_size = be32_to_cpu(dsb->dsb_block_size); asb->asb_root_inode = be32_to_cpu(dsb->dsb_root_inode); asb->asb_inodes_in_block = asb->asb_block_size / sizeof(struct aufs_disk_inode); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

जैसा कि आप अनुमान लगा सकते हैं, be32_to_cpu फ़ंक्शन प्लेटफ़ॉर्म द्वारा उपयोग किए जाने वाले बाइट ऑर्डर के लिए एक नंबर को धर्मान्तरित करता है।



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



आखिरी चीज जो हम करते हैं वह जादू की संख्या की जांच करता है, हमें यह सुनिश्चित करने की आवश्यकता है कि वास्तव में aufs डिस्क पर संग्रहीत है।



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



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



हमने सुपरब्लॉक पढ़ने के लिए एक फ़ंक्शन लिखा, हम इसे aufs_fill_super (पिछली पोस्ट देखें) से कॉल करेंगे, अब यह इस तरह दिखता है:

 static int aufs_fill_sb(struct super_block *sb, void *data, int silent) { struct inode *root = NULL; struct aufs_super_block *asb = aufs_super_block_read(sb); if (!asb) return -EINVAL; sb->s_magic = asb->asb_magic; sb->s_fs_info = asb; sb->s_op = &aufs_super_ops; if (sb_set_blocksize(sb, asb->asb_block_size) == 0) { pr_err("device does not support block size %u\n", (unsigned)asb->asb_block_size); return -EINVAL; } root = aufs_inode_get(sb, asb->asb_root_inode); if (IS_ERR(root)) return PTR_ERR(root); sb->s_root = d_make_root(root); if (!sb->s_root) { pr_err("aufs cannot create root\n"); return -ENOMEM; } return 0; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

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



इसलिए हमने गतिशील मेमोरी में aufs_super_block आवंटित किया, जिसका अर्थ है कि हमें इसे मुक्त करना होगा। ऐसा करने के लिए, हमें अंतिम पोस्ट से किसी अन्य फ़ंक्शन में कुछ बदलाव करने की आवश्यकता है:

 static void aufs_put_super(struct super_block *sb) { struct aufs_super_block *asb = (struct aufs_super_block *)sb->s_fs_info; if (asb) kfree(asb); sb->s_fs_info = NULL; pr_debug("aufs super block destroyed\n"); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

यह अनुमान लगाना मुश्किल नहीं है कि केफ्री फ़ंक्शन को kmalloc फ़ंक्शन के साथ अधिक युग्मित किया गया है, अधिक सटीक रूप से फ़ंक्शन भी, क्योंकि कर्नेल में कई kfree कार्यान्वयन हैं (अभी भी यहाँ और यहाँ ), लेकिन हम विवरण में नहीं गए।



Aufs_fill_sb फ़ंक्शन के अंदर एक और महत्वपूर्ण परिवर्तन aufs_inode_get के लिए कॉल है। पिछले लेख में, हमने एक डमी इनोड बनाया, अब हम सीखेंगे कि उन्हें डिस्क से कैसे पढ़ा जाए।



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



हम सुपर नोड्स संरचना का विस्तार करके सूचकांक नोड्स के साथ काम करना शुरू करेंगे, जो हमने पिछली बार मुलाकात की थी। अब हम इसे इस तरह भरेंगे:

 static struct super_operations const aufs_super_ops = { .alloc_inode = aufs_inode_alloc, .destroy_inode = aufs_inode_free, .put_super = aufs_put_super, };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

हमने aufs_inode_alloc और aufs_inode_free फ़ंक्शंस में कुछ और संकेत जोड़े। इनोड को आवंटित करने और जारी करने के लिए ये विशिष्ट कार्य हैं, यहां हम SLAB (हम पहले से ही इस जानवर को kmalloc के रूप में सामना कर चुके हैं) और RCU (काफी थोड़ा) का सामना करेंगे।



इसलिए, हम एक और संरचना को परिभाषित करके सूचकांक नोड के लिए मेमोरी का आवंटन शुरू करेंगे - मेमोरी में इंडेक्स नोड का प्रतिनिधित्व करते हुए (जैसा कि सुपरब्लॉक के साथ था):

 struct aufs_inode { struct inode ai_inode; uint32_t ai_block; };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

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



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



इंडेक्स नोड्स के लिए मेमोरी आवंटित करने के लिए, हम SLAB एलोकेटर का उपयोग करेंगे। SLAB एलोकेटर - एक कैशिंग आवंटनकर्ता जो आपको एक ही आकार के मेमोरी ब्लॉक आवंटित करने की अनुमति देता है। यह अनुमान लगाना कठिन नहीं है कि इस सीमा के कारण, स्मृति प्रबंधन को सरल बनाया जा सकता है और स्मृति आवंटन में तेजी लाई जा सकती है। SLAB आवंटनकर्ता मेमोरी के बड़े हिस्से के लिए OS पर सवाल करता है और अनुरोध पर क्रमशः उनसे छोटे खंड आवंटित करता है, OS मेमोरी मैनेजर के लिए अनुरोध कम होते हैं, और उपयोगकर्ता अनुरोध तेजी से होते हैं।



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



वर्तमान में, लिनक्स में तीन अलग-अलग प्रकार के SLAB एलोकेटर हैं - SLAB, SLUB और SLOB। हम उनके बीच मतभेदों में नहीं जाएंगे, वे एक ही इंटरफ़ेस प्रदान करते हैं। तो, एक SLAB एलोकेटर बनाने के लिए, हम निम्नलिखित फ़ंक्शन का उपयोग करेंगे:

 int aufs_inode_cache_create(void) { aufs_inode_cache = kmem_cache_create("aufs_inode", sizeof(struct aufs_inode), 0, (SLAB_RECLAIM_ACCOUNT|SLAB_MEM_SPREAD), aufs_inode_init_once); if (aufs_inode_cache == NULL) return -ENOMEM; return 0; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

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



हम कर्नेल में फ़ाइल सिस्टम को पंजीकृत करने से पहले मॉड्यूल को लोड करते समय aufs_inode_cache_create फ़ंक्शन को कॉल करेंगे। एक जोड़ी फ़ंक्शन भी है जिसे हम मॉड्यूल अनलोड होने पर कॉल करेंगे:

 void aufs_inode_cache_destroy(void) { rcu_barrier(); kmem_cache_destroy(aufs_inode_cache); aufs_inode_cache = NULL; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Kmem_cache_destroy फ़ंक्शन SLAB आवंटनकर्ता को नष्ट कर देता है।विनाश के समय तक, इस कैश से सभी ऑब्जेक्ट्स को मुक्त किया जाना चाहिए, अन्यथा हम सिस्टम लॉग में एक अप्रिय त्रुटि संदेश प्राप्त करेंगे, साथ ही हार्ड-टू-कैच मुसीबतों का एक पूरा गुच्छा।



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



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



स्मृति आबंटन पर वापस जाते हैं, ऊपर उल्लिखित फ़ंक्शन पर विचार करें:

 struct inode *aufs_inode_alloc(struct super_block *sb) { struct aufs_inode *const i = (struct aufs_inode *) kmem_cache_alloc(aufs_inode_cache, GFP_KERNEL); if (!i) return NULL; return &i->ai_inode; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

यह पहले से बनाए गए SLAB एलोकेटर ( kmem_cache_alloc कार्यान्वयन में से एक के माध्यम से ) का उपयोग करता है और इनोड में एक पॉइंटर लौटाता है - कुछ भी असामान्य नहीं है, लेकिन रिलीज़ फ़ंक्शन थोड़ा और दिलचस्प है:

 void aufs_inode_free(struct inode *inode) { call_rcu(&inode->i_rcu, aufs_free_callback); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

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



क्या आप थके हुए हैं?यह ठीक है, हम पहले से ही समापन के करीब पहुंच रहे हैं। अब हम डिस्क से इंडेक्स नोड को पढ़ेंगे। ऐसा करने के लिए, मैंने पहले ही उल्लिखित aufs_inode_get फ़ंक्शन लिखा है:

 struct inode *aufs_inode_get(struct super_block *sb, uint32_t no) { struct aufs_super_block const *const asb = AUFS_SB(sb); struct buffer_head *bh = NULL; struct aufs_disk_inode *di = NULL; struct aufs_inode *ai = NULL; struct inode *inode = NULL; uint32_t block = 0, offset = 0; inode = iget_locked(sb, no); if (!inode) return ERR_PTR(-ENOMEM); if (!(inode->i_state & I_NEW)) return inode; ai = AUFS_INODE(inode); block = aufs_inode_block(asb, no); offset = aufs_inode_offset(asb, no); pr_debug("aufs reads inode %u from %u block with offset %u\n", (unsigned)no, (unsigned)block, (unsigned)offset); bh = sb_bread(sb, block); if (!bh) { pr_err("cannot read block %u\n", (unsigned)block); goto read_error; } di = (struct aufs_disk_inode *)(bh->b_data + offset); aufs_inode_fill(ai, di); brelse(bh); unlock_new_inode(inode); return inode; read_error: pr_err("aufs cannot read inode %u\n", (unsigned)no); iget_failed(inode); return ERR_PTR(-EIO); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

मैं सरल बिंदुओं के साथ शुरू करूँगा - AUFS_SB और AUFS_INODE फ़ंक्शन आपको क्रमशः पॉइंटर्स से सुपर_ब्लॉक और इनोड में aufs_super_block और aufs_inode संरचनाओं के लिए एक संकेतक प्राप्त करने की अनुमति देते हैं। मैं उनका कोड नहीं दूंगा (यह काफी सरल है), क्योंकि मैंने पहले ही ऊपर वर्णित किया है कि ये संरचनाएं कैसे जुड़ी हुई हैं।



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



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



तो idet_locked फ़ंक्शन सबसे पहले कैश में इनोड की तलाश करता है और इनोड नहीं मिलने पर एक नए के लिए मेमोरी आवंटित करता है। यदि इंडेक्स नोड को फिर से आवंटित किया गया था, लेकिन कैश में नहीं मिला, तो I_NEW ध्वज i_state फ़ील्ड में सेट किया जाएगा, और इस नोड का स्पिनलॉक कैप्चर किया जाएगा (i_lock फ़ील्ड)। इसलिए, हमारा फ़ंक्शन पहले i_state फ़ील्ड की जांच करता है, और यदि I_NEW ध्वज साफ़ हो जाता है, तो हम बस कैश्ड इनकोड वापस करते हैं। अन्यथा, हमें इनोड भरना चाहिए, इसके लिए हम डिस्क से वांछित ब्लॉक पढ़ते हैं (पहले से ही ज्ञात sb_bread का उपयोग करके)।



Aufs_inode_fill फ़ंक्शन केवल फिलिंग करता है:

 static void aufs_inode_fill(struct aufs_inode *ai, struct aufs_disk_inode const *di) { ai->ai_block = be32_to_cpu(di->di_first); ai->ai_inode.i_mode = be32_to_cpu(di->di_mode); ai->ai_inode.i_size = be32_to_cpu(di->di_size); ai->ai_inode.i_blocks = be32_to_cpu(di->di_blocks); ai->ai_inode.i_ctime.tv_sec = be64_to_cpu(di->di_ctime); ai->ai_inode.i_mtime.tv_sec = ai->ai_inode.i_atime.tv_sec = ai->ai_inode.i_ctime.tv_sec; ai->ai_inode.i_mtime.tv_nsec = ai->ai_inode.i_atime.tv_nsec = ai->ai_inode.i_ctime.tv_nsec = 0; i_uid_write(&ai->ai_inode, (uid_t)be32_to_cpu(di->di_uid)); i_gid_write(&ai->ai_inode, (gid_t)be32_to_cpu(di->di_gid)); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

फिर, कोई जादू नहीं, सिवाय i_uid_write और i_gid_write फ़ंक्शन की जोड़ी के । लेकिन वे कुछ विशेष नहीं करते हैं - वे बस संबंधित क्षेत्रों को मान प्रदान करते हैं।



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



अंत में, फ़ंक्शन के बहुत अंत में, हमें स्पिनलॉक को मुक्त करना होगा और पॉइंटर को वापस करना होगा, इसके लिए हम unlock_new_inode फ़ंक्शन का उपयोग करते हैं।

एक निष्कर्ष के बजाय

यह पोस्ट वास्तव में बड़ी है और यहां तक ​​कि सभी बिंदुओं को कवर नहीं करती है। मैंने कार्यान्वयन के सभी प्रमुख भागों को समझाने की कोशिश की।



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



बढ़ते के लिए एक डिस्क छवि प्राप्त करने के लिए, आप यह कर सकते हैं:

 dd bs=1M count=100 if=/dev/zero of=image ./mkfs.aufs ./image
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

अब आप छवि फ़ाइल का उपयोग कर सकते हैं जैसा कि पिछले पोस्ट में दिखाया गया है।



हमने इस लेख में कोड उदाहरणों में से कुछ नमूना आउटपुट को हटा दिया है, लेकिन यदि आप भंडार से कोड का उपयोग करते हैं, तो आप यह सत्यापित कर सकते हैं कि मॉड्यूल dmesg कमांड का उपयोग करके काम करता है।