🍟 🔫 🤛🏻 लिनक्स कर्नेल फ़ाइल सिस्टम लिखना 👨🏾‍⚕️ 🏳️ 🎭

यह लेख किसके लिए है?

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

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

परिचय

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

पर्यावरण की स्थापना

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

sudo apt-get install gcc build-essential

अगला, हमें कर्नेल स्रोतों की आवश्यकता है, या आवश्यकता नहीं है। हम सरल तरीके से जाएंगे - हम स्रोतों से कर्नेल का पुनर्निर्माण नहीं करेंगे, बस अपने लिए कर्नेल हेडर सेट करें, यह एक लोड करने योग्य मॉड्यूल लिखने के लिए पर्याप्त होगा। आप इस तरह हेडर सेट कर सकते हैं:

sudo apt-get install linux-headers-`uname -r`

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

पर्यावरण की जाँच

पर्यावरण की जांच करने के लिए, एक कर्नेल मॉड्यूल लिखें और चलाएं जो कुछ भी उपयोगी नहीं होगा (हैलो, वर्ल्ड!)। आइए मॉड्यूल कोड को देखें, मैंने इसे सुपर सी कहा है (कुछ भी मत सोचो, सुपर सुपरब्लॉक से है):

  #include <linux/init.h> #include <linux/module.h> static int __init aufs_init(void) { pr_debug("aufs module loaded\n"); return 0; } static void __exit aufs_fini(void) { pr_debug("aufs module unloaded\n"); } module_init(aufs_init); module_exit(aufs_fini); MODULE_LICENSE("GPL"); MODULE_AUTHOR("kmu");

बहुत शुरुआत में दो हेडर हैं, विचार करें कि वे किसी भी लोड करने योग्य कर्नेल मॉड्यूल का एक अनिवार्य हिस्सा हैं, उनमें कुछ भी दिलचस्प नहीं है। अगले दो कार्य aufs_init और aufs_fini हैं - उन्हें क्रमशः लोड करने के बाद और मॉड्यूल को उतारने से पहले कहा जाएगा।

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

ध्यान दें कि aufs_init एक int देता है। इस प्रकार, कर्नेल को पता चलता है कि मॉड्यूल आरंभीकरण के दौरान कुछ गलत हो गया है - यदि मॉड्यूल एक गैर-शून्य मान लौटाता है, तो प्रारंभ के दौरान एक त्रुटि हुई।

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

pr_debug एक फ़ंक्शन है (वास्तव में यह एक मैक्रो है, लेकिन अब यह हमारे लिए महत्वपूर्ण नहीं है) कर्नेल लॉग के लिए आउटपुट करने के लिए, कुछ एक्सटेंशन वाले फ़ंक्शन का प्रिंटफ़ परिवार बहुत समान है, उदाहरण के लिए, आईपी और मैक पते को प्रिंट करने के लिए। मॉडिफायर्स की पूरी सूची कर्नेल डॉक्यूमेंटेशन में मिल सकती है। Pr_debug के साथ, मैक्रोज़ का एक पूरा परिवार है: pr_info, pr_warn, pr_err और अन्य। जो लोग लिनक्स मॉड्यूल के विकास से थोड़ा परिचित हैं, वे शायद प्रिंट फ़ंक्शन के बारे में जानते हैं, सिद्धांत रूप में, pr_ * मैक्रोज़ को प्रिंट कॉल में विस्तारित किया जाता है, इसलिए आप सीधे इसके बजाय प्रिंट का उपयोग कर सकते हैं।

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

अब हम अपने मॉड्यूल को इकट्ठा करेंगे और लोड करेंगे। ऐसा करने के लिए, एक Makefile लिखें जो हमारा मॉड्यूल बनाएगा:

 obj-m := aufs.o aufs-objs := super.o CFLAGS_super.o := -DDEBUG all: make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules clean: make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean

वास्तव में, यह बिल्ड मेकफाइल कर्नेल मेकफाइल को कॉल करता है, जो / lib / मॉड्यूल / $ (शेल uname -r) / बिल्ड में स्थित होना चाहिए (uname -r वह कमांड है जो रनिंग कर्नेल का संस्करण लौटाता है) यदि आप हेडर (या) सूत्रों) गुठली एक और निर्देशिका में हैं, तो आपको इसे ठीक करने की आवश्यकता है।

obj-m - आपको भविष्य के मॉड्यूल के नाम को निर्दिष्ट करने की अनुमति देता है, हमारे मामले में मॉड्यूल को aufs.ko (जैसे ko - कर्नेल ऑब्जेक्ट से) कहा जाएगा। और aufs-objs आपको aufs मॉड्यूल बनाने के लिए किस सोर्स फाइल से निर्दिष्ट करने की अनुमति देता है, हमारे मामले में केवल एक सुपर सी सी फ़ाइल का उपयोग किया जाएगा। इसके अलावा, आप विभिन्न कंपाइलर फ़्लैग को निर्दिष्ट कर सकते हैं, जिनका उपयोग किया जाएगा (कर्नेल मेकफाइल द्वारा उपयोग किए जाने के अलावा) ऑब्जेक्ट फ़ाइलों का निर्माण करते समय, हमारे मामले में मैं सुपर-सीड का निर्माण करते समय -DDEBUG ध्वज पास करता हूं। यदि आप -DDEBUG ध्वज को पास नहीं करते हैं, तो हम सिस्टम लॉग में pr_debug आउटपुट नहीं देखेंगे।

मॉड्यूल बनाने के लिए, आपको मेक कमांड को चलाने की आवश्यकता है। यदि सब कुछ ठीक है, तो aufs.ko फ़ाइल निर्देशिका में दिखाई देनी चाहिए - यह हमारा डाउनलोड करने योग्य मॉड्यूल है। मॉड्यूल डाउनलोड करना काफी सरल है:

sudo insmod ./aufs.ko

यह सत्यापित करने के लिए कि मॉड्यूल लोड हो गया है, आप लसमोड कमांड के आउटपुट को देख सकते हैं:

lsmod | grep aufs

सिस्टम लॉग को देखने के लिए आपको dmesg कमांड को कॉल करने की आवश्यकता है, और वहां हमें अपने मॉड्यूल से संदेश देखना चाहिए। मॉड्यूल को उतारना भी मुश्किल नहीं है:

sudo rmmod aufs

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

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

फ़ाइल सिस्टम का जीवन पंजीकरण के साथ शुरू होता है। आप register_filesystem पर कॉल करके एक फ़ाइल सिस्टम रजिस्टर कर सकते हैं। हम मॉड्यूल इनिशियलाइज़ेशन फंक्शन के साथ फाइल सिस्टम रजिस्टर करेंगे। फ़ाइल सिस्टम को अपंजीकृत करने के लिए, unregister_filesystem फ़ंक्शन है, और हम इसे अपने मॉड्यूल के aufs_fini फ़ंक्शन में कहेंगे।

दोनों कार्य एक पैरामीटर के रूप में file_system_type संरचना के लिए एक संकेतक के रूप में लेते हैं - यह फ़ाइल सिस्टम का "वर्णन" करेगा, इसे फ़ाइल सिस्टम का एक वर्ग मानें। इस संरचना में पर्याप्त क्षेत्र हैं, लेकिन हम केवल उनमें से कुछ में रुचि रखते हैं:

  static struct file_system_type aufs_type = { .owner = THIS_MODULE, .name = "aufs", .mount = aufs_mount, .kill_sb = kill_block_super, .fs_flags = FS_REQUIRES_DEV, };

सबसे पहले, हम नाम क्षेत्र में रुचि रखते हैं, यह फ़ाइल सिस्टम के नाम को संग्रहीत करता है, यह यह नाम है जो बढ़ते समय उपयोग किया जाएगा, लेकिन बाद में उस पर अधिक, बस इसे याद रखें।

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

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

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

अब aufs_mount फ़ंक्शन पर विचार करें। इसे डिवाइस को माउंट करना चाहिए और फाइल सिस्टम की रूट डायरेक्टरी का वर्णन करते हुए एक स्ट्रक्चर वापस करना चाहिए। यह बल्कि जटिल लगता है, लेकिन, सौभाग्य से, यहाँ कर्नेल हमारे लिए लगभग सब कुछ करेगा:

  static struct dentry *aufs_mount(struct file_system_type *type, int flags, char const *dev, void *data) { struct dentry *const entry = mount_bdev(type, flags, dev, data, aufs_fill_sb); if (IS_ERR(entry)) pr_err("aufs mounting failed\n"); else pr_debug("aufs mounted\n"); return entry; }

वास्तव में, अधिकांश कार्य moun_bdev फ़ंक्शन के अंदर होते हैं, हम केवल इसके पैरामीटर aufs_fill_sb में रुचि रखते हैं - यह फ़ंक्शन (फिर से) के लिए एक पॉइंटर है जो सुपरब्लॉक को आरंभीकृत करने के लिए Mount_bdev से बुलाया जाएगा। लेकिन इससे पहले कि हम उस पर आगे बढ़ें, हम डेंट्री संरचना पर ध्यान केंद्रित करेंगे, जो कर्नेल की फ़ाइल सबसिस्टम के लिए महत्वपूर्ण है। यह संरचना फ़ाइल नाम में पथ के एक हिस्से का प्रतिनिधित्व करती है, उदाहरण के लिए, यदि हम फ़ाइल / usr / bin / vim का उपयोग करते हैं, तो हमारे पास पथ के कुछ हिस्सों (रूट डायरेक्टरी), bin / और vim का प्रतिनिधित्व करने वाली मंद संरचना के उदाहरण होंगे। कर्नेल इन संरचनाओं के कैश का समर्थन करता है, जो आपको फ़ाइल के नाम (पथ) द्वारा इनोड (दूसरा केंद्र संरचना) को जल्दी से खोजने की अनुमति देता है। इसलिए, aufs_mount फ़ंक्शन को हमारी फ़ाइल सिस्टम की मूल निर्देशिका का प्रतिनिधित्व करने वाले डेंट्री को वापस करना चाहिए, और aufs_fill_sb फ़ंक्शन इसे बनाएगा।

इसलिए, aufs_fill_sb हमारे मॉड्यूल में अब तक का सबसे महत्वपूर्ण कार्य है, और यह इस तरह दिखता है:

  static int aufs_fill_sb(struct super_block *sb, void *data, int silent) { struct inode *root = NULL; sb->s_magic = AUFS_MAGIC_NUMBER; sb->s_op = &aufs_super_ops; root = new_inode(sb); if (!root) { pr_err("inode allocation failed\n"); return -ENOMEM; } root->i_ino = 0; root->i_sb = sb; root->i_atime = root->i_mtime = root->i_ctime = CURRENT_TIME; inode_init_owner(root, NULL, S_IFDIR); sb->s_root = d_make_root(root); if (!sb->s_root) { pr_err("root creation failed\n"); return -ENOMEM; } return 0; }

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

इसके अलावा, सुपर_ब्लॉक संरचना के s_op फ़ील्ड में, हम सुपर_ऑपरेशन्स संरचना के लिए एक पॉइंटर को स्टोर करते हैं - ये सुपर_ब्लॉक के "क्लास तरीके" हैं, अर्थात्, एक अन्य संरचना जो फ़ंक्शन पॉइंटर्स का एक गुच्छा संग्रहीत करती है।

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

लेकिन वापस सुपर_ब्लॉक संरचना और इसके "तरीकों" पर, हम अब सुपर_ऑपरेशंस संरचना के विवरण में नहीं जाएंगे, हम इसके केवल एक क्षेत्र - put_super में रुचि रखेंगे। Put_super में हम अपने सुपरब्लॉक के "विध्वंसक" को बचाएंगे:

  static void aufs_put_super(struct super_block *sb) { pr_debug("aufs super block destroyed\n"); } static struct super_operations const aufs_super_ops = { .put_super = aufs_put_super, };

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

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

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

फ्रेम की जाँच

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

touch image

इसके अलावा, हमें एक निर्देशिका बनाने की आवश्यकता है जो हमारे फाइल सिस्टम का आरोह बिंदु (रूट) होगी:

mkdir dir

अब इस छवि का उपयोग करते हुए, हमारी फाइल सिस्टम को माउंट करें:

sudo mount -o loop -t aufs ./image ./dir

यदि ऑपरेशन सफलतापूर्वक पूरा हुआ, तो सिस्टम लॉग में हमें अपने मॉड्यूल से संदेश देखना चाहिए। फ़ाइल सिस्टम को अनमाउंट करने के लिए, यह करें:

sudo umount ./dir

और फिर से हम सिस्टम लॉग की जांच करते हैं।

परिणाम

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

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

संदर्भ और संदर्भ

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

लिनक्स कर्नेल फ़ाइल सिस्टम लिखना