लिनक्समध्ये व्हर्च्युअल फाइल सिस्टम: त्यांची आवश्यकता का आहे आणि ते कसे कार्य करतात? भाग 2

सर्वांना नमस्कार, आम्ही तुमच्यासोबत प्रकाशनाचा दुसरा भाग शेअर करत आहोत “Linux मधील Virtual file systems: त्यांची गरज का आहे आणि ते कसे कार्य करतात?” पहिला भाग तुम्ही वाचू शकता येथे. आम्‍ही तुम्‍हाला स्मरण करून देऊ या की प्रकाशनांची ही मालिका अभ्यासक्रमावर एक नवीन प्रवाह सुरू होण्‍याशी जुळून आली आहे. "लिनक्स प्रशासक", जे लवकरच सुरू होईल.

eBPF आणि bcc टूल्स वापरून VFS चे निरीक्षण कसे करावे

कर्नल फाइल्सवर कसे कार्य करते हे समजून घेण्याचा सर्वात सोपा मार्ग sysfs ते प्रत्यक्ष व्यवहारात पाहणे आहे, आणि ARM64 पाहण्याचा सर्वात सोपा मार्ग म्हणजे eBPF वापरणे. eBPF (बर्कले पॅकेट फिल्टरसाठी लहान) मध्ये एक आभासी मशीन कार्यरत असते कोर, जे विशेषाधिकार प्राप्त वापरकर्ते विनंती करू शकतात (query) कमांड लाइनवरून. कर्नल स्रोत वाचकांना कर्नल काय करू शकतात ते सांगतात; लोडेड सिस्टीमवर eBPF टूल्स चालवणे कर्नल प्रत्यक्षात काय करत आहे हे दर्शवते.

सुदैवाने, टूल्सच्या मदतीने eBPF वापरणे सुरू करणे खूप सोपे आहे बीसीसी, जे सामान्य वितरणातून पॅकेजेस म्हणून उपलब्ध आहेत linux आणि तपशीलवार दस्तऐवजीकरण बर्नार्ड ग्रेग. साधने bcc पायथन स्क्रिप्ट्स सी कोडच्या लहान इन्सर्टेशनसह आहेत, याचा अर्थ असा आहे की दोन्ही भाषांशी परिचित कोणीही त्यांना सहजपणे सुधारू शकतो. IN bcc/tools तेथे 80 पायथन स्क्रिप्ट आहेत, ज्याचा अर्थ बहुधा विकसक किंवा सिस्टम प्रशासक समस्या सोडवण्यासाठी योग्य काहीतरी निवडण्यास सक्षम असेल.
VFS चालू असलेल्या प्रणालीवर काय काम करतात याची किमान वरवरची कल्पना मिळविण्यासाठी प्रयत्न करा vfscount किंवा vfsstat. हे दर्शवेल, चला म्हणू, की डझनभर कॉल vfs_open() आणि "त्याचे मित्र" अक्षरशः दर सेकंदाला घडतात.

vfsstat.py सी कोड इन्सर्ट असलेली पायथन स्क्रिप्ट आहे जी फक्त व्हीएफएस फंक्शन कॉल मोजते.

चला आणखी क्षुल्लक उदाहरण देऊ आणि जेव्हा आपण संगणकात USB फ्लॅश ड्राइव्ह टाकतो आणि सिस्टमला ते सापडते तेव्हा काय होते ते पाहू.

eBPF वापरून तुम्ही पाहू शकता की काय होत आहे /sysजेव्हा USB फ्लॅश ड्राइव्ह घातली जाते. एक साधे आणि गुंतागुंतीचे उदाहरण येथे दर्शविले आहे.

वर दाखवलेल्या उदाहरणात, bcc इन्स्ट्रुमेंट trace.py कमांड रन झाल्यावर मेसेज प्रिंट करते sysfs_create_files(). आम्ही ते पाहतो sysfs_create_files() वापरून लाँच केले होते kworker फ्लॅश ड्राइव्ह घातल्याच्या प्रतिसादात प्रवाह, परंतु कोणती फाइल तयार केली गेली? दुसरे उदाहरण eBPF चे सामर्थ्य दाखवते. येथे trace.py कर्नल बॅकट्रेस (-K पर्याय) आणि तयार केलेल्या फाइलचे नाव मुद्रित करते sysfs_create_files(). सिंगल स्टेटमेंट इन्सर्शन म्हणजे C कोड ज्यामध्ये LLVM चालवणाऱ्या Python स्क्रिप्टद्वारे प्रदान केलेल्या सहज ओळखण्यायोग्य फॉरमॅट स्ट्रिंगचा समावेश आहे जस्ट-इन-टाइम कंपाइलर. ते ही ओळ संकलित करते आणि कर्नलच्या आत वर्च्युअल मशीनमध्ये कार्यान्वित करते. पूर्ण कार्य स्वाक्षरी sysfs_create_files () दुसऱ्या कमांडमध्ये पुनरुत्पादित करणे आवश्यक आहे जेणेकरून फॉरमॅट स्ट्रिंग पॅरामीटर्सपैकी एकाचा संदर्भ घेऊ शकेल. C कोडच्या या तुकड्यातील त्रुटींमुळे C कंपाइलरकडून ओळखण्यायोग्य त्रुटी येतात. उदाहरणार्थ, -l पॅरामीटर वगळल्यास, तुम्हाला "BPF मजकूर संकलित करण्यात अयशस्वी" दिसेल. सी आणि पायथनशी परिचित असलेल्या विकसकांना साधने सापडतील bcc विस्तार आणि बदलण्यास सोपे.

USB ड्राइव्ह घातल्यावर, कर्नल बॅकट्रेस दाखवेल की PID 7711 एक थ्रेड आहे. kworkerज्याने फाइल तयार केली «events» в sysfs. त्यानुसार कडून फोन आला sysfs_remove_files() दाखवेल की ड्राइव्ह काढून टाकल्याने फाइल हटवली गेली events, जे संदर्भ मोजणीच्या सामान्य संकल्पनेशी संबंधित आहे. त्याच वेळी, पाहणे sysfs_create_link () eBPF सह USB ड्राइव्ह टाकताना दिसून येईल की किमान 48 प्रतीकात्मक दुवे तयार केले आहेत.

मग इव्हेंट फाईलचा मुद्दा काय आहे? वापर cscope शोधासाठी __डिव्हाइस_जोडा_डिस्क(), ते काय कारणीभूत आहे ते दर्शविते disk_add_events (), आणि एकतर "media_change", किंवा "eject_request" इव्हेंट फाइलमध्ये रेकॉर्ड केले जाऊ शकते. येथे कर्नल ब्लॉक लेयर युजरस्पेसला सूचित करते की "डिस्क" दिसली आणि बाहेर काढली गेली. यूएसबी ड्राइव्ह टाकून ही संशोधन पद्धत किती माहितीपूर्ण आहे हे लक्षात घ्या, गोष्टी पूर्णपणे स्त्रोतावरून कशा कार्य करतात हे शोधण्याचा प्रयत्न करण्याच्या तुलनेत.

केवळ-वाचनीय रूट फाइल सिस्टम एम्बेडेड डिव्हाइसेस सक्षम करतात

अर्थात, सॉकेटमधून प्लग ओढून कोणीही सर्व्हर किंवा त्यांचा संगणक बंद करत नाही. पण का? याचे कारण असे की फिजिकल स्टोरेज डिव्हायसेसवर माउंट केलेल्या फाईल सिस्टीममध्ये लॅग्ड राइट्स असू शकतात, आणि डेटा स्ट्रक्चर्स जे त्यांची स्थिती रेकॉर्ड करतात ते स्टोरेजमध्ये राइटसह सिंक्रोनाइझ केले जाऊ शकत नाहीत. जेव्हा हे घडते, तेव्हा युटिलिटी लाँच करण्यासाठी सिस्टम मालकांना पुढील बूट होईपर्यंत प्रतीक्षा करावी लागेल. fsck filesystem-recovery आणि, सर्वात वाईट परिस्थितीत, डेटा गमावणे.

तथापि, आपल्या सर्वांना माहित आहे की अनेक IoT उपकरणे, तसेच राउटर, थर्मोस्टॅट्स आणि कार, आता Linux चालवतात. यापैकी बर्‍याच उपकरणांमध्ये वापरकर्ता इंटरफेस नसतो आणि त्यांना "स्वच्छपणे" बंद करण्याचा कोणताही मार्ग नाही. कंट्रोल युनिटला पॉवर असताना मृत बॅटरीने कार सुरू करण्याची कल्पना करा linux सतत वर आणि खाली उडी मारणे. हे कसे आहे की सिस्टम लाँगशिवाय बूट होते fsckइंजिन शेवटी कधी चालू होते? आणि उत्तर सोपे आहे. एम्बेडेड उपकरणे रूट फाइल सिस्टमवर अवलंबून असतात फक्त वाचनासाठी (संक्षिप्त ro-rootfs (केवळ-वाचनीय रूट फाइल सिस्टम)).

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

निर्मिती rootfs एम्बेडेड डेव्हलपरसाठी फक्त-वाचण्यासाठी काही अतिरिक्त प्रयत्नांची आवश्यकता आहे आणि येथेच VFS चित्रात येतो. लिनक्समध्ये फाइल्स असणे आवश्यक आहे /var लिहिण्यायोग्य होते, आणि याव्यतिरिक्त, एम्बेडेड सिस्टम चालवणारे अनेक लोकप्रिय अनुप्रयोग कॉन्फिगरेशन तयार करण्याचा प्रयत्न करतील dot-files в $HOME. होम डिरेक्टरीमधील कॉन्फिगरेशन फाइल्ससाठी एक उपाय म्हणजे ते पूर्व-उत्पन्न करणे आणि तयार करणे rootfs. साठी /var एक संभाव्य दृष्टीकोन म्हणजे ते वेगळ्या लेखन करण्यायोग्य विभाजनावर माउंट करणे / केवळ-वाचनीय आरोहित. दुसरा लोकप्रिय पर्याय म्हणजे बाइंड किंवा आच्छादन माउंट वापरणे.

लिंक करण्यायोग्य आणि स्टॅक करण्यायोग्य माउंट, कंटेनरद्वारे त्यांचा वापर

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

आच्छादन आणि लिंक करण्यायोग्य माउंटच्या वर्णनावर आधारित, कोणालाही आश्चर्य वाटले नाही लिनक्स कंटेनर ते सक्रियपणे वापरले जातात. आपण वापरतो तेव्हा काय होते ते पाहूया systemd-nspawn साधन वापरून कंटेनर चालविण्यासाठी mountsnoop पासून bcc.

आव्हान system-nspawn चालू असताना कंटेनर सुरू करतो mountsnoop.py.

काय झाले ते पाहूया:

लाँच करा mountsnoop कंटेनर "बूटिंग" असताना हे दर्शविते की कंटेनरचा रनटाइम माउंट जोडलेल्यावर अवलंबून असतो (फक्त लांब आउटपुटची सुरुवात दर्शविली जाते).

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

निष्कर्ष

लिनक्सचे अंतर्गत कार्य समजून घेणे अशक्य वाटू शकते, कारण कर्नलमध्येच मोठ्या प्रमाणात कोड असतो, लिनक्स वापरकर्ता स्पेस ऍप्लिकेशन्स आणि सी लायब्ररीमधील सिस्टम कॉल इंटरफेस बाजूला ठेवून glibc. प्रगती करण्याचा एक मार्ग म्हणजे एका कर्नल सबसिस्टमचा सोर्स कोड वाचणे, ज्यामध्ये सिस्टम कॉल्स आणि यूजर-स्पेस हेडर, तसेच मुख्य अंतर्गत कर्नल इंटरफेस, जसे की टेबल समजून घेणे यावर भर दिला जातो. file_operations. फाइल ऑपरेशन्स "सर्व काही एक फाइल आहे" तत्त्व प्रदान करतात, त्यांना व्यवस्थापित करण्यासाठी विशेषतः आनंददायक बनवतात. उच्च-स्तरीय निर्देशिकेत C कर्नल स्त्रोत फाइल्स fs/ व्हर्च्युअल फाइल सिस्टमची अंमलबजावणी सादर करते, जे लोकप्रिय फाइल सिस्टम आणि स्टोरेज डिव्हाइसेसमध्ये व्यापक आणि तुलनेने सोपी सुसंगतता प्रदान करणारे रॅपर स्तर आहे. लिनक्स नेमस्पेसेसद्वारे लिंक करणे आणि आच्छादित करणे ही VFS ची जादू आहे ज्यामुळे केवळ वाचनीय कंटेनर आणि रूट फाइल सिस्टम तयार करणे शक्य होते. सोर्स कोड, eBPF कोर टूल आणि त्याच्या इंटरफेसच्या परीक्षणासह एकत्रित bcc
मूळ शोध नेहमीपेक्षा सोपे बनवणे.

मित्रांनो, लिहा, हा लेख तुमच्यासाठी उपयुक्त होता का? कदाचित तुमच्याकडे काही टिप्पण्या किंवा टिप्पण्या आहेत? आणि ज्यांना लिनक्स अॅडमिनिस्ट्रेटर कोर्समध्ये स्वारस्य आहे त्यांना आमंत्रित केले आहे खुला दिवस, जे 18 एप्रिल रोजी होणार आहे.

पहिला भाग.

स्त्रोत: www.habr.com