लिनक्स वर्चुअल फाइल सिस्टम: उनकी आवश्यकता क्यों है और वे कैसे काम करते हैं? भाग २

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

VFS को EBPF और bcc टूल के साथ कैसे देखें

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



सौभाग्य से, ईएक्सपीएफ का उपयोग करना शुरू करना बीसीसी टूल्स के साथ काफी आसान है, जो सामान्य लिनक्स वितरण से पैकेज के रूप में उपलब्ध हैं और बर्नार्ड ग्रीग द्वारा विस्तार से प्रलेखित हैं। bcc उपकरण छोटे C कोड आवेषण के साथ पायथन स्क्रिप्ट हैं, जिसका अर्थ है कि जो भी दोनों भाषाओं से परिचित हैं, उन्हें आसानी से संशोधित कर सकते हैं। bcc/tools में 80 पायथन स्क्रिप्ट हैं, जिसका अर्थ है कि सबसे अधिक संभावना है कि डेवलपर या सिस्टम व्यवस्थापक समस्या को हल करने के लिए उपयुक्त कुछ चुन पाएंगे।

चल रहे सिस्टम पर VFS क्या करता है, इसका भी सतही विचार प्राप्त करने के लिए, vfscount या vfsstat । यह दिखाएगा, उदाहरण के लिए, कि vfs_open() और "उसके दोस्तों" को दर्जनों कॉल शाब्दिक रूप से हर vfs_open() होते हैं।

vfsstat.py , C कोड आवेषण के साथ एक पायथन स्क्रिप्ट है जो केवल VFS फ़ंक्शन कॉल की गणना करता है।

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

EBPF का उपयोग करके, आप देख सकते हैं कि USB फ्लैश ड्राइव डालने पर /sys में क्या होता है। एक सरल और जटिल उदाहरण यहाँ दिखाया गया है।

ऊपर दिए गए उदाहरण में, sysfs_create_files() कमांड sysfs_create_files() bcc टूल ट्रेसहोम एक संदेश प्रदर्शित करता है। हम देखते हैं कि फ़्लैश ड्राइव के डाले जाने के जवाब में kworker स्ट्रीम का उपयोग करके sysfs_create_files() लॉन्च किया गया था, लेकिन कौन सी फ़ाइल बनाई गई थी? दूसरा उदाहरण eBPF की पूर्ण शक्ति को दर्शाता है। यहां trace.py कर्नेल बैकट्रेस ( trace.py विकल्प) और फ़ाइल का नाम प्रदर्शित करता है जो sysfs_create_files() द्वारा बनाई गई थी। एकल कथन प्रविष्टि C कोड है जिसमें Python स्क्रिप्ट द्वारा प्रदान किया जाने वाला आसानी से पहचाना जाने वाला प्रारूप स्ट्रिंग शामिल है जो LLVM को सिर्फ-इन-टाइम संकलक चलाता है। वह इस लाइन को कर्नेल के अंदर एक वर्चुअल मशीन में संकलित और निष्पादित करता है। sysfs_create_files () फ़ंक्शन के पूर्ण हस्ताक्षर को दूसरी कमांड में पुन: प्रस्तुत किया जाना चाहिए ताकि प्रारूप स्ट्रिंग मापदंडों में से एक का उल्लेख कर सके। इस सी कोड के टुकड़े में त्रुटियां पहचानने योग्य सी संकलक त्रुटियों में परिणाम करती हैं। उदाहरण के लिए, यदि आप -l विकल्प को छोड़ देते हैं, तो आप देखेंगे "बीपीएफ पाठ संकलित करने में विफल।" डेवलपर्स जो C और पायथन से परिचित हैं, उन्हें bcc टूल को विस्तार और संशोधित करने में आसान लगेगा।

जब USB ड्राइव डाला जाता है, तो एक कर्नेल kworker दिखाएगा कि PID 7711 kworker स्ट्रीम है जिसने «events» फ़ाइल को sysfs । तदनुसार, sysfs_remove_files() साथ एक कॉल दिखाएगा कि ड्राइव को हटाने से events फ़ाइल को हटा दिया गया events , जो संदर्भ गिनती की सामान्य अवधारणा के अनुरूप है। उसी समय, USB ड्राइव सम्मिलित करते समय eBPF के साथ sysfs_create_link () को देखने से पता चलेगा कि कम से कम 48 प्रतीकात्मक लिंक बनाए गए हैं।

तो घटनाओं फ़ाइल का अर्थ क्या है? __Device_add_disk () को खोजने के लिए cscope का उपयोग करने से पता चलता है कि यह disk_add_events () कॉल disk_add_events () , और या तो "media_change" या "eject_request" को ईवेंट फ़ाइल में लिखा जा सकता है। यहाँ, कर्नेल ब्लॉक लेयर "डिस्क" की उपस्थिति और निष्कर्षण के उपयोगकर्ताओं को सूचित करता है। कृपया ध्यान दें कि यह शोध विधि यूएसबी ड्राइव को सम्मिलित करने के उदाहरण से कितनी उपयोगी है, यह जानने की कोशिश करें कि सब कुछ कैसे काम करता है, विशेष रूप से स्रोत से।

केवल-रूट फ़ाइल सिस्टम एम्बेडेड डिवाइस को सक्षम करता है

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

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

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

rootfs बनाने के लिए एम्बेडेड डेवलपर्स के लिए कुछ अतिरिक्त प्रयास की आवश्यकता होती है, और यही वह जगह है जहां वीएफएस दृश्य पर आता है। लिनक्स के लिए आवश्यक है कि फ़ाइलें /var में लिखने योग्य हो, और इसके अलावा, एम्बेडेड सिस्टम चलाने वाले कई लोकप्रिय एप्लिकेशन $HOME में कॉन्फ़िगरेशन dot-files बनाने की कोशिश करेंगे। होम निर्देशिका में कॉन्फ़िगरेशन फ़ाइलों के लिए समाधानों में से एक आमतौर पर rootfs में उनकी प्रारंभिक पीढ़ी और असेंबली है। /var संभव दृष्टिकोणों में से एक इसे एक अलग अनुभाग में माउंट करना है जो कि लेखन योग्य है, जबकि / माउंट स्वयं रीड-ओनली है। एक अन्य लोकप्रिय विकल्प बाइंड या ओवरले माउंट का उपयोग करना है।

जोड़ने योग्य और अतिव्यापी माउंट, कंटेनरों द्वारा उनका उपयोग

man mount कमांड चलाना मैप्ड और सुपरइम्पोज़्ड माउंट्स के बारे में जानने का सबसे अच्छा तरीका है जो डेवलपर्स और सिस्टम एडमिनिस्ट्रेटर को एक तरह से फाइल सिस्टम बनाने की क्षमता देता है और फिर दूसरे में एप्लिकेशन प्रदान करता है। एम्बेडेड सिस्टम के लिए, इसका मतलब है कि रीड-ओनली फ्लैश ड्राइव पर /var में फाइलों को स्टोर करने की क्षमता, लेकिन बूट पर tmpfs से /var तक के रास्ते को tmpfs या लिंक करने से एप्लिकेशन को वहां नोट्स लिखने में मदद मिलेगी (स्क्रैवल)। अगली बार जब आप इसे सक्षम करते हैं, तो /var में परिवर्तन खो जाएगा। एक ओवरलैड माउंट tmpfs और अंतर्निहित फ़ाइल सिस्टम के बीच एक संघ बनाता है और आपको ro-tootf में मौजूदा फ़ाइलों को कथित रूप से संशोधित करने की अनुमति देता है, जबकि एक लिंक किया गया माउंट नए खाली tmpfs फ़ोल्डरों को ro-rootfs पथों में लिखने योग्य ro-rootfs है। जबकि overlayfs एक proper प्रकार की फ़ाइल प्रणाली है, VFS नामस्थान में बाइंडिंग माउंट लागू होते हैं।

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



mountsnoop.py जबकि mountsnoop.py system-nspawn लिए कॉल कंटेनर शुरू करता mountsnoop.py ।

आइए देखें क्या हुआ:



कंटेनर "बूट" के दौरान mountsnoop चलाना इंगित करता है कि कंटेनर रनटाइम कनेक्ट होने वाले माउंट पर अत्यधिक निर्भर है (केवल लंबे आउटपुट की शुरुआत प्रदर्शित होती है)।

यहां, systemd-nspawn मेजबान के procfs और sysfs में चयनित फ़ाइलों को उसके rootfs लिए पथ के रूप में कंटेनर को प्रदान करता है। MS_BIND ध्वज के अलावा, जो बाध्यकारी माउंट को सेट करता है, माउंटेड सिस्टम में कुछ अन्य झंडे मेजबान नाम स्थान और कंटेनर में परिवर्तन के बीच संबंध निर्धारित करते हैं। उदाहरण के लिए, एक बाध्यकारी माउंट या तो कंटेनर में /proc और /sys में परिवर्तन को छोड़ सकता है, या कॉल के आधार पर उन्हें छिपा सकता है।

निष्कर्ष

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

दोस्तों, इस लेख को लिखना आपके लिए उपयोगी था? शायद आपके पास कोई टिप्पणी या टिप्पणी है? और जो लोग लिनक्स प्रशासक के पाठ्यक्रम में रुचि रखते हैं, हम आपको घर का दिन खोलने के लिए आमंत्रित करते हैं , जो 18 अप्रैल को होगा।

पहला भाग।