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

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

ईबीपीएफ और बीसीसी टूल का उपयोग करके वीएफएस की निगरानी कैसे करें

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

सौभाग्य से, टूल की मदद से eBPF का उपयोग शुरू करना काफी आसान है गुप्त प्रतिलिपि, जो सामान्य वितरण से पैकेज के रूप में उपलब्ध हैं Linux और विस्तार से प्रलेखित किया गया बर्नार्ड ग्रेग. औजार bcc सी कोड के छोटे सम्मिलन के साथ पायथन स्क्रिप्ट हैं, जिसका अर्थ है कि दोनों भाषाओं से परिचित कोई भी व्यक्ति उन्हें आसानी से संशोधित कर सकता है। में bcc/tools 80 पायथन स्क्रिप्ट हैं, जिसका अर्थ है कि संभवतः एक डेवलपर या सिस्टम प्रशासक समस्या को हल करने के लिए कुछ उपयुक्त चुनने में सक्षम होगा।
कम से कम एक सतही विचार प्राप्त करने के लिए कि VFS किसी चालू सिस्टम पर क्या कार्य करता है, प्रयास करें vfscount या vfsstat. मान लीजिए, यह दिखाएगा कि दर्जनों कॉलें vfs_open() और "उसके दोस्त" वस्तुतः हर सेकंड होते हैं।

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

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

ईबीपीएफ का उपयोग करके आप देख सकते हैं कि क्या हो रहा है /sysजब USB फ्लैश ड्राइव डाला जाता है। एक सरल और जटिल उदाहरण यहां दिखाया गया है.

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

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

तो इवेंट फ़ाइल का क्या मतलब है? प्रयोग सीस्कोप खोज के लिए __डिवाइस_ऐड_डिस्क(), दिखाता है कि इसका क्या कारण है disk_add_events (), और या तो "media_change"या "eject_request" इवेंट फ़ाइल में रिकॉर्ड किया जा सकता है. यहां कर्नेल ब्लॉक परत उपयोगकर्ता स्थान को सूचित करती है कि एक "डिस्क" प्रकट हुई है और बाहर निकल गई है। ध्यान दें कि यूएसबी ड्राइव डालकर यह शोध पद्धति कितनी जानकारीपूर्ण है, इसकी तुलना में यह पता लगाने की कोशिश की जाती है कि चीजें पूरी तरह से स्रोत से कैसे काम करती हैं।

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

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

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

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

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

लिंक करने योग्य और स्टैकेबल माउंट, कंटेनरों द्वारा उनका उपयोग

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

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

कॉल system-nspawn चलते समय कंटेनर चालू करता है mountsnoop.py.

देखते है क्या हुआ:

Запуск mountsnoop जबकि कंटेनर "बूटिंग" कर रहा है, यह दर्शाता है कि कंटेनर का रनटाइम लिंक किए जा रहे माउंट पर अत्यधिक निर्भर है (केवल लंबे आउटपुट की शुरुआत दिखाई गई है)।

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

निष्कर्ष

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

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

पहला भाग।

स्रोत: www.habr.com