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

नमस्ते सबैलाई, हामी तपाइँसँग प्रकाशनको दोस्रो भाग साझा गर्दैछौं "लिनक्समा भर्चुअल फाइल प्रणालीहरू: तिनीहरू किन आवश्यक छन् र तिनीहरूले कसरी काम गर्छन्?" पहिलो भाग पढ्न सक्नुहुन्छ यहाँ। हामी तपाईंलाई सम्झना गरौं कि प्रकाशनहरूको यो शृङ्खला पाठ्यक्रममा नयाँ स्ट्रिमको सुरुवातसँग मिल्ने समय हो। "लिनक्स प्रशासक", जुन चाँडै सुरु हुन्छ।

eBPF र bcc उपकरणहरू प्रयोग गरेर VFS कसरी निगरानी गर्ने

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

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

vfsstat.py C कोड सम्मिलित भएको पाइथन स्क्रिप्ट हो जसले केवल VFS प्रकार्य कलहरू गणना गर्दछ।

अझ सानो उदाहरण दिऔं र हेरौं के हुन्छ जब हामीले कम्प्युटरमा USB फ्लैश ड्राइव घुसाउँछौं र प्रणालीले यसलाई पत्ता लगाउँछ।

eBPF प्रयोग गरेर तपाईले के भइरहेको छ हेर्न सक्नुहुन्छ /sysजब USB फ्लैश ड्राइव सम्मिलित हुन्छ। एक सरल र जटिल उदाहरण यहाँ देखाइएको छ।

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

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

त्यसोभए घटना फाइलको बिन्दु के हो? प्रयोग cscope खोजको लागि __device_add_disk(), यसले के कारण बनाउँछ भनेर देखाउँछ disk_add_events (), र या त "media_change", वा "eject_request" घटना फाइलमा रेकर्ड गर्न सकिन्छ। यहाँ कर्नेल ब्लक तहले प्रयोगकर्ता स्पेसलाई "डिस्क" देखा परेको र बाहिर निकालेको जानकारी दिन्छ। कुराहरू स्रोतबाट विशुद्ध रूपमा कसरी काम गर्छ भनी पत्ता लगाउने प्रयासको तुलनामा USB ड्राइभ घुसाएर यो अनुसन्धान विधि कत्तिको जानकारीमूलक छ भनेर ध्यान दिनुहोस्।

पढ्ने-मात्र रूट फाइल प्रणालीले इम्बेडेड उपकरणहरू सक्षम पार्छ

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

यद्यपि, हामी सबैलाई थाहा छ कि धेरै IoT उपकरणहरू, साथै राउटरहरू, थर्मोस्टेटहरू र कारहरू, अब लिनक्स चलाउँछन्। यी धेरै यन्त्रहरूमा कुनै प्रयोगकर्ता इन्टरफेस छैन, र तिनीहरूलाई "स्वच्छ रूपमा" बन्द गर्ने कुनै तरिका छैन। कन्ट्रोल युनिटमा पावर हुँदा मृत ब्याट्रीको साथ कार सुरु गर्ने कल्पना गर्नुहोस् लिनक्स लगातार माथि र तल उफ्रदै। यो कसरी लामो समय बिना प्रणाली बुट छ fsckइन्जिन अन्ततः कहिले चल्न थाल्छ? र जवाफ सरल छ। इम्बेडेड यन्त्रहरू रूट फाइल प्रणालीमा निर्भर हुन्छन् पढ्नको लागि मात्र (संक्षिप्त ro-rootfs (पढ्न-मात्र रूट फाइल प्रणाली))।

ro-rootfs धेरै फाइदाहरू प्रदान गर्नुहोस् जुन प्रामाणिकता भन्दा कम स्पष्ट छन्। एउटा फाइदा यो हो कि मालवेयरले लेख्न सक्दैन /usr वा /lib, यदि कुनै लिनक्स प्रक्रियाले त्यहाँ लेख्न सक्दैन। अर्को भनेको रिमोट यन्त्रहरूको फिल्ड समर्थनको लागि ठूलो रूपमा अपरिवर्तनीय फाइल प्रणाली महत्त्वपूर्ण छ, किनकि समर्थन कर्मचारीहरू स्थानीय प्रणालीहरूमा भर पर्छन् जुन फिल्ड प्रणालीहरूसँग नाममात्र समान छन्। सायद सबैभन्दा महत्त्वपूर्ण (तर सबैभन्दा कपटी) फाइदा यो हो कि ro-rootfs ले विकासकर्ताहरूलाई प्रणालीको डिजाइन चरणमा कुन प्रणाली वस्तुहरू अपरिवर्तनीय हुनेछ भनेर निर्णय गर्न बाध्य पार्छ। ro-rootfs सँग काम गर्नु अप्ठ्यारो र पीडादायी हुन सक्छ, किनकि const चरहरू प्राय: प्रोग्रामिङ भाषाहरूमा हुन्छन्, तर तिनीहरूका फाइदाहरूले सजिलैसँग अतिरिक्त ओभरहेडलाई औचित्य दिन्छ।

सिर्जना rootfs इम्बेडेड विकासकर्ताहरूका लागि केवल पढ्नको लागि केही अतिरिक्त प्रयास चाहिन्छ, र यो जहाँ VFS चित्रमा आउँछ। Linux लाई फाइलहरू भित्र हुन आवश्यक छ /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 कन्टेनरमा, वा कलको आधारमा तिनीहरूलाई लुकाउनुहोस्।

निष्कर्षमा

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

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

पहिलो भाग।

स्रोत: www.habr.com