Sýndarskráarkerfi í Linux: hvers vegna er þörf á þeim og hvernig virka þau? 2. hluti

Halló allir, við erum að deila með ykkur seinni hluta útgáfunnar „Sýndarskráarkerfi í Linux: hvers vegna er þörf á þeim og hvernig virka þau? Þú getur lesið fyrsta hlutann hér. Við skulum minna þig á að þessi ritsería er tímasett til að falla saman við upphaf nýs straums á námskeiðinu "Linux stjórnandi", sem hefst mjög fljótlega.

Hvernig á að fylgjast með VFS með eBPF og bcc verkfærum

Auðveldasta leiðin til að skilja hvernig kjarninn virkar á skrám sysfs er að sjá það í reynd og auðveldasta leiðin til að horfa á ARM64 er að nota eBPF. eBPF (stutt fyrir Berkeley Packet Filter) samanstendur af sýndarvél sem keyrir inn kjarni, sem forréttindanotendur geta beðið um (query) frá skipanalínunni. Kjarnaheimildirnar segja lesandanum hvað kjarninn getur gert; að keyra eBPF verkfærin á hlaðnu kerfi sýnir hvað kjarninn er í raun að gera.

Sýndarskráarkerfi í Linux: hvers vegna er þörf á þeim og hvernig virka þau? 2. hluti

Sem betur fer er auðvelt að byrja að nota eBPF með hjálp verkfæra bcc, sem eru fáanlegir sem pakkar frá almennri dreifingu Linux og skjalfest ítarlega Bernard Gregg. Verkfæri bcc eru Python forskriftir með litlum innsetningum af C kóða, sem þýðir að allir sem þekkja bæði tungumálin geta auðveldlega breytt þeim. IN bcc/tools Það eru 80 Python forskriftir, sem þýðir að líklegast mun verktaki eða kerfisstjóri geta valið eitthvað sem hentar til að leysa vandamálið.
Til að fá að minnsta kosti yfirborðslega hugmynd um hvaða vinnu VFSs vinna á keyrandi kerfi, reyndu vfscount eða vfsstat. Þetta mun sýna, við skulum segja, að tugir símtala vfs_open() og „vinir hans“ gerast bókstaflega á hverri sekúndu.

Sýndarskráarkerfi í Linux: hvers vegna er þörf á þeim og hvernig virka þau? 2. hluti

vfsstat.py er Python forskrift með C kóða innskotum sem einfaldlega telur VFS fallakall.

Við skulum gefa léttvægara dæmi og sjá hvað gerist þegar við setjum USB-drifi í tölvu og kerfið skynjar það.

Sýndarskráarkerfi í Linux: hvers vegna er þörf á þeim og hvernig virka þau? 2. hluti

Með því að nota eBPF geturðu séð hvað er að gerast í /sysþegar USB glampi drif er sett í. Hér er sýnt einfalt og flókið dæmi.

Í dæminu sem sýnt er hér að ofan, bcc инструмент trace.py prentar skilaboð þegar skipunin er keyrð sysfs_create_files(). Við sjáum það sysfs_create_files() var hleypt af stokkunum með því að nota kworker streyma til að bregðast við því að flash-drifið var sett í, en hvaða skrá var búin til? Annað dæmið sýnir kraft eBPF. Hérna trace.py Prentar kjarna bakslag (-K valkostur) og nafn skráarinnar sem var búin til sysfs_create_files(). Innsetning á einni yfirlýsingu er C-kóði sem inniheldur auðþekkjanlegan sniðstreng sem er frá Python skriftunni sem keyrir LLVM réttlátur þýðandi. Það setur þessa línu saman og keyrir hana í sýndarvél inni í kjarnanum. Full virkni undirskrift sysfs_create_files () verður að afrita í annarri skipuninni svo að sniðstrengurinn geti átt við eina af færibreytunum. Villur í þessum C kóða leiða til auðþekkjanlegra villna frá C þýðandanum. Til dæmis, ef -l færibreytunni er sleppt, muntu sjá "Mistókst að setja saman BPF texta." Hönnuðir sem þekkja C og Python munu finna verkfærin bcc auðvelt að stækka og breyta.

Þegar USB drifið er sett í mun kjarnabakhlaupið sýna að PID 7711 er þráður kworkersem bjó til skrána «events» в sysfs. Í samræmi við það er símtal frá sysfs_remove_files() mun sýna að það að fjarlægja drifið leiddi til þess að skránni var eytt events, sem samsvarar almennu hugtakinu viðmiðunartalningu. Á sama tíma að skoða sysfs_create_link () með eBPF á meðan USB-drifið er sett í mun sýna að að minnsta kosti 48 táknrænir tenglar hafa verið búnir til.

Svo hver er tilgangurinn með atburðaskránni? Notkun cscope Til leitar __device_add_disk(), sýnir hvað það veldur disk_add_events (), og annaðhvort "media_change"Eða "eject_request" hægt að skrá í atburðaskrá. Hér lætur kjarnablokkalagið notendarými vita að "diskur" hafi birst og kastað út. Athugaðu hversu upplýsandi þessi rannsóknaraðferð er með því að setja inn USB drif, samanborið við að reyna að komast að því hvernig hlutirnir virka eingöngu frá upprunanum.

Skrifvarið rótarskráarkerfi gera innbyggð tæki kleift

Auðvitað slekkur enginn á þjóninum eða tölvunni sinni með því að draga klóið úr innstungunni. En afhverju? Þetta er vegna þess að uppsett skráarkerfi á líkamlegum geymslutækjum kunna að hafa seinkun á skrifum og gagnaskipulag sem skráir ástand þeirra gæti ekki verið samstillt við skrif í geymsluna. Þegar þetta gerist þurfa kerfiseigendur að bíða þar til næsta ræsi er til að ræsa tólið. fsck filesystem-recovery og í versta falli tapa gögnum.

Hins vegar vitum við öll að mörg IoT tæki, svo og beinar, hitastillar og bílar, keyra nú Linux. Mörg þessara tækja hafa lítið sem ekkert notendaviðmót og það er engin leið að slökkva á þeim "hreint". Ímyndaðu þér að ræsa bíl með tæmdu rafhlöðu þegar straumurinn á stjórneininguna er Linux hoppa stöðugt upp og niður. Hvernig er það að kerfið ræsir sig án þess að vera lengi fsckhvenær byrjar vélin loksins að ganga? Og svarið er einfalt. Innbyggð tæki treysta á rótarskráarkerfið aðeins til lestrar (skammstafað ro-rootfs (skrifvarið rót skráarkerfi)).

ro-rootfs bjóða upp á marga kosti sem eru minna augljósir en áreiðanleiki. Einn kostur er að spilliforrit getur ekki skrifað til /usr eða /lib, ef ekkert Linux ferli getur skrifað þar. Annað er að að mestu óbreytanlegt skráarkerfi er mikilvægt fyrir vettvangsstuðning fjartengdra tækja, þar sem stuðningsstarfsmenn treysta á staðbundin kerfi sem eru að nafninu til eins og vettvangskerfin. Kannski er mikilvægasti (en líka skaðlegasti) ávinningurinn sá að ro-rootfs neyðir þróunaraðila til að ákveða hvaða kerfishlutir verða óbreytanlegir á hönnunarstigi kerfisins. Að vinna með ro-rootfs getur verið óþægilegt og sársaukafullt, þar sem const breytur eru oft í forritunarmálum, en ávinningur þeirra réttlætir auðveldlega aukakostnaðinn.

sköpun rootfs Read-only krefst nokkurrar fyrirhafnar fyrir innbyggða forritara og það er þar sem VFS kemur inn í myndina. Linux krefst þess að skrár séu í /var voru skrifanleg og að auki munu mörg vinsæl forrit sem keyra innbyggð kerfi reyna að búa til stillingar dot-files в $HOME. Ein lausn fyrir stillingarskrár í heimaskránni er venjulega að búa þær til og byggja þær inn í þær rootfs. Fyrir /var Ein möguleg nálgun er að tengja það á sérstakt skrifanlegt skipting, á meðan / uppsettur skrifvarinn. Annar vinsæll valkostur er að nota bindi- eða yfirborðsfestingar.

Tengjanlegar og staflanlegar festingar, notkun þeirra með gámum

Framkvæmd skipunar man mount er besta leiðin til að fræðast um bindanlegar og yfirlögnar festingar, sem gefa forriturum og kerfisstjórum möguleika á að búa til skráarkerfi á einni slóð og afhjúpa það síðan fyrir forritum í annarri. Fyrir innbyggð kerfi þýðir þetta getu til að geyma skrár í /var á skrifvarandi flassdrifi, en yfirlags- eða tengislóð frá tmpfs в /var við hleðslu mun það leyfa forritum að skrifa glósur þar (skrolla). Næst þegar þú kveikir á breytingunum á /var mun glatast. Yfirlagsfesting skapar samband á milli tmpfs og undirliggjandi skráarkerfi og gerir þér kleift að gera áberandi breytingar á núverandi skrám í ro-tootf en bindanleg festing getur gert nýjar tómar tmpfs möppur sýnilegar sem skrifanlegar í ro-rootfs leiðir. Meðan overlayfs þetta er rétta (proper) skráarkerfisgerð, bindanleg festing er útfærð í VFS nafnrými.

Byggt á lýsingunni á yfirborðinu og tengjanlegu festingunni er enginn hissa á því Linux gámar þau eru notuð á virkan hátt. Við skulum sjá hvað gerist þegar við notum systemd-nspawn til að keyra ílátið með því að nota tólið mountsnoop frá bcc.

Hringdu system-nspawn ræsir gáminn á meðan hann er í gangi mountsnoop.py.

Við skulum sjá hvað gerðist:

Ræstu mountsnoop á meðan gámurinn er að "ræsa" sýnir að keyrslutími gámsins er mjög háður því að fjallið sé tengt (Aðeins upphaf langa úttaksins er sýnt).

Hér systemd-nspawn veitir valdar skrár í procfs и sysfs hýsir í gám sem leiðir að honum rootfs. Að auki MS_BIND fána sem setur upp bindingu fjallsins, sumir aðrir fánar á fjallinu skilgreina tengslin milli breytinga á hýsil og gáma nafnrými. Til dæmis getur tengd fjall annað hvort sleppt breytingum á /proc и /sys inn í gáminn, eða fela þá eftir símtalinu.

Ályktun

Að skilja innri virkni Linux getur virst vera ómögulegt verkefni, þar sem kjarninn sjálfur inniheldur mikið magn af kóða, að sleppa Linux notendarýmisforritum og kerfissímtölum í C bókasöfnum eins og glibc. Ein leið til að ná framförum er að lesa frumkóðann eins kjarna undirkerfis, með áherslu á að skilja kerfiskall og notendarýmishausa, sem og helstu innri kjarnaviðmót, svo sem töflur. file_operations. Skráaaðgerðir veita „allt er skrá“ meginregluna, sem gerir þær sérstaklega skemmtilegar í umsjón. C kjarna frumskrár í efstu möppunni fs/ kynna útfærslu sýndarskráakerfa, sem eru umbúðir sem veitir víðtæka og tiltölulega einfalda samhæfni milli vinsælra skráarkerfa og geymslutækja. Tenging og uppsetning á yfirborði í gegnum Linux nafnrými er galdurinn við VFS sem gerir það mögulegt að búa til skrifvarinn gáma og rótarskráarkerfi. Ásamt athugun á frumkóðanum, eBPF kjarnaverkfærinu og viðmóti þess bcc
gera kjarnakönnun auðveldari en nokkru sinni fyrr.

Vinir, skrifaðu, var þessi grein gagnleg fyrir þig? Kannski hefurðu einhverjar athugasemdir eða athugasemdir? Og þeim sem hafa áhuga á Linux Administrator námskeiðinu er boðið á Opinn dagur, sem fer fram 18. apríl.

Fyrsti hluti.

Heimild: www.habr.com

Bæta við athugasemd