Hamjambo, tunashiriki nanyi sehemu ya pili ya uchapishaji "Mifumo ya faili pepe katika Linux: kwa nini inahitajika na inafanya kazi vipi?" Unaweza kusoma sehemu ya kwanza . Hebu tukumbushe kwamba mfululizo huu wa machapisho umepitwa na wakati ili sanjari na uzinduzi wa mkondo mpya kwenye kozi. , ambayo inaanza hivi karibuni.
Jinsi ya kufuatilia VFS kwa kutumia eBPF na zana za bcc
Njia rahisi zaidi ya kuelewa jinsi kernel inavyofanya kazi kwenye faili sysfs ni kuiona kwa vitendo, na njia rahisi ya kutazama ARM64 ni kutumia eBPF. eBPF (fupi kwa Kichujio cha Pakiti ya Berkeley) ina mashine pepe inayoingia , ambayo watumiaji waliobahatika wanaweza kuomba (query) kutoka kwa safu ya amri. Vyanzo vya kernel humwambia msomaji kile kernel inaweza kufanya; kuendesha zana za eBPF kwenye mfumo uliopakiwa kunaonyesha kile kernel inafanya.
Kwa bahati nzuri, kuanza kutumia eBPF ni rahisi sana kwa msaada wa zana , ambazo zinapatikana kama vifurushi kutoka kwa usambazaji wa jumla na kumbukumbu kwa undani . Zana bcc ni hati za Python zilizo na viingilio vidogo vya msimbo wa C, ambayo ina maana kwamba mtu yeyote anayefahamu lugha zote mbili anaweza kuzirekebisha kwa urahisi. KATIKA bcc/tools Kuna hati 80 za Python, ambayo ina maana kwamba uwezekano mkubwa wa msanidi programu au msimamizi wa mfumo ataweza kuchagua kitu kinachofaa kwa kutatua tatizo.
Ili kupata angalau wazo la juu juu la kazi ya VFS kwenye mfumo unaoendesha, jaribu vfscount au vfsstat. Hii itaonyesha, tuseme, kwamba kadhaa ya simu vfs_open() na "rafiki zake" hutokea halisi kila sekunde.
vfsstat.pyni hati ya Python iliyo na viingilio vya msimbo wa C ambavyo huhesabu tu simu za kazi za VFS.
Hebu tutoe mfano usio na maana zaidi na tuone kinachotokea tunapoingiza gari la USB flash kwenye kompyuta na mfumo huigundua.
Kwa kutumia eBPF unaweza kuona kinachoendelea ndani
/syswakati gari la USB flash limeingizwa. Mfano rahisi na mgumu unaonyeshwa hapa.
Katika mfano ulioonyeshwa hapo juu, bcc chombo huchapisha ujumbe wakati amri inaendeshwa sysfs_create_files(). Tunaona hilo sysfs_create_files() ilizinduliwa kwa kutumia kworker mkondo kwa kukabiliana na ukweli kwamba gari la flash liliingizwa, lakini ni faili gani iliundwa? Mfano wa pili unaonyesha nguvu ya eBPF. Hapa trace.py Huchapisha nyuma ya kernel (chaguo-K) na jina la faili ambayo iliundwa sysfs_create_files(). Uingizaji wa taarifa moja ni msimbo C unaojumuisha mfuatano wa umbizo unaotambulika kwa urahisi unaotolewa na hati ya Python inayoendesha LLVM. mkusanyaji wa wakati tu. Inakusanya laini hii na kuitekeleza kwenye mashine pepe ndani ya kernel. Sahihi kamili ya utendaji sysfs_create_files () lazima itolewe tena katika amri ya pili ili kamba ya umbizo iweze kurejelea mojawapo ya vigezo. Hitilafu katika kipande hiki cha msimbo C husababisha makosa yanayotambulika kutoka kwa mkusanyaji wa C. Kwa mfano, ikiwa kigezo cha -l kimeachwa, utaona "Imeshindwa kukusanya maandishi ya BPF." Watengenezaji ambao wanafahamu C na Python watapata zana bcc rahisi kupanua na kubadilisha.
Wakati kiendeshi cha USB kinapoingizwa, nyuma ya kernel itaonyesha kuwa PID 7711 ni nyuzi. kworkerambayo imeunda faili Β«eventsΒ» Π² sysfs. Ipasavyo, simu kutoka sysfs_remove_files() itaonyesha kuwa kuondoa kiendeshi kulisababisha faili kufutwa events, ambayo inalingana na dhana ya jumla ya kuhesabu kumbukumbu. Wakati huo huo, kutazama sysfs_create_link () na eBPF wakati wa kuingiza kiendeshi cha USB itaonyesha kuwa angalau viungo 48 vya ishara vimeundwa.
Kwa hivyo ni nini maana ya faili ya matukio? Matumizi Kwa utafutaji , inaonyesha nini husababisha disk_add_events (), na ama "media_change"Au "eject_request" inaweza kurekodiwa katika faili ya tukio. Hapa safu ya kuzuia kernel inaarifu nafasi ya watumiaji kuwa "diski" imeonekana na kutolewa. Kumbuka jinsi mbinu hii ya utafiti ilivyo ya kuelimisha kwa kuingiza hifadhi ya USB, ikilinganishwa na kujaribu kubaini jinsi mambo yanavyofanya kazi kutoka kwa chanzo pekee.
Mifumo ya faili za mizizi ya kusoma pekee huwezesha vifaa vilivyopachikwa
Bila shaka, hakuna mtu anayezima seva au kompyuta yao kwa kuvuta kuziba kutoka kwenye tundu. Lakini kwa nini? Hii ni kwa sababu mifumo ya faili zilizopachikwa kwenye vifaa halisi vya kuhifadhi inaweza kuwa na maandishi yaliyochelewa, na miundo ya data inayorekodi hali yao inaweza isilandanishwe na kuandika kwenye hifadhi. Hii inapotokea, wamiliki wa mfumo wanapaswa kusubiri hadi buti inayofuata ili kuzindua matumizi. fsck filesystem-recovery na, katika hali mbaya zaidi, kupoteza data.
Hata hivyo, sisi sote tunajua kwamba vifaa vingi vya IoT, pamoja na routers, thermostats na magari, sasa vinaendesha Linux. Mengi ya vifaa hivi havina kiolesura kidogo cha mtumiaji, na hakuna njia ya kuzima "kwa usafi." Hebu fikiria kuanzisha gari na betri iliyokufa wakati nguvu ya kitengo cha kudhibiti iko mara kwa mara kuruka juu na chini. Je, ni jinsi gani kwamba mfumo wa buti bila muda mrefu fsckmwishowe injini inaanza kufanya kazi lini? Na jibu ni rahisi. Vifaa vilivyopachikwa hutegemea mfumo wa faili wa mizizi (kifupi ro-rootfs (mfumo wa faili wa kusoma tu)).
ro-rootfs kutoa faida nyingi ambazo hazionekani zaidi kuliko uhalisi. Faida moja ni kwamba programu hasidi haiwezi kumwandikia /usr au /lib, ikiwa hakuna mchakato wa Linux unaweza kuandika hapo. Nyingine ni kwamba mfumo wa faili usiobadilika kwa kiasi kikubwa ni muhimu kwa usaidizi wa uga wa vifaa vya mbali, kwa kuwa wafanyakazi wa usaidizi hutegemea mifumo ya ndani ambayo inafanana kwa jina na mifumo ya uga. Labda manufaa muhimu zaidi (lakini pia ya siri zaidi) ni kwamba ro-rootfs huwalazimisha watengenezaji kuamua ni vitu vipi vya mfumo haviwezi kubadilika katika hatua ya muundo wa mfumo. Kufanya kazi na ro-rootfs kunaweza kuwa jambo gumu na chungu, kwani vigeuzo vya const mara nyingi huwa katika lugha za programu, lakini faida zake huhalalisha kwa urahisi nyongeza ya ziada.
viumbe rootfs Kusoma-tu kunahitaji juhudi za ziada kwa wasanidi waliopachikwa, na hapa ndipo VFS inapokuja kwenye picha. Linux inahitaji faili ziwe ndani /var ziliweza kuandikwa, na kwa kuongeza, programu nyingi maarufu zinazoendesha mifumo iliyopachikwa zitajaribu kuunda usanidi dot-files Π² $HOME. Suluhisho moja la faili za usanidi kwenye saraka ya nyumbani kawaida ni kutengeneza na kuziunda ndani rootfs. Kwa /var Njia moja inayowezekana ni kuiweka kwenye kizigeu tofauti kinachoweza kuandikwa, wakati / imewekwa kwa kusoma pekee. Njia nyingine maarufu ni kutumia vifungo vya kufunga au kufunika.
Milima inayoweza kuunganishwa na inayoweza kushikana, matumizi yao na vyombo
Utekelezaji wa amri man mount ndiyo njia bora ya kujifunza juu ya vitu vya kupachika vinavyoweza kubabika na vinavyoweza kuwekwa juu, ambavyo vinawapa wasanidi programu na wasimamizi wa mfumo uwezo wa kuunda mfumo wa faili katika njia moja na kisha kuionyesha kwa programu katika nyingine. Kwa mifumo iliyopachikwa, hii inamaanisha uwezo wa kuhifadhi faili ndani /var kwenye kiendeshi cha kusomeka pekee, lakini njia inayowekelea au inayoweza kuunganishwa kutoka tmpfs Π² /var wakati wa kupakia, itawawezesha programu kuandika maelezo huko (kupiga). Wakati mwingine ukiwasha mabadiliko /var itapotea. Mlima wa juu unaunda muungano kati ya tmpfs na mfumo wa msingi wa faili na hukuruhusu kufanya mabadiliko yanayoonekana kwa faili zilizopo ro-tootf ilhali mlima unaoweza kufungwa unaweza kufanya mpya tupu tmpfs folda zinazoonekana kama zinazoweza kuandikwa ndani ro-rootfs njia. Wakati overlayfs hii ndio sahihi (proper) aina ya mfumo wa faili, mlima unaoweza kufungwa unatekelezwa ndani .
Kulingana na maelezo ya muunganisho na mlima unaoweza kuunganishwa, hakuna anayeshangaa hilo zinatumika kikamilifu. Wacha tuone nini kinatokea tunapotumia kuendesha chombo kwa kutumia chombo mountsnoop kutoka bcc.
Changamoto system-nspawn huanza chombo wakati wa kukimbia mountsnoop.py.
Hebu tuone kilichotokea:
Uzindua mountsnoop wakati kontena "linawasha" inaonyesha kuwa muda wa kukimbia wa kontena unategemea sana mlima unaounganishwa (Mwanzo tu wa matokeo ya muda mrefu ndio umeonyeshwa).
Hapa systemd-nspawn hutoa faili zilizochaguliwa ndani procfs ΠΈ sysfs mwenyeji kwa kontena kama njia zake rootfs. Mbali na hilo MS_BIND bendera inayoweka sehemu ya kupachika inayofunga, bendera zingine kwenye mlima hufafanua uhusiano kati ya mabadiliko ya nafasi za majina za seva pangishi na kontena. Kwa mfano, kipandikizi kilichounganishwa kinaweza kuruka mabadiliko hadi /proc ΠΈ /sys kwenye chombo, au uzifiche kulingana na simu.
Hitimisho
Kuelewa utendakazi wa ndani wa Linux kunaweza kuonekana kama kazi isiyowezekana, kwani kernel yenyewe ina idadi kubwa ya nambari, ukiacha matumizi ya nafasi ya mtumiaji wa Linux na miingiliano ya simu ya mfumo katika maktaba za C kama vile. glibc. Njia moja ya kufanya maendeleo ni kusoma msimbo wa chanzo wa mfumo mdogo wa kernel, na msisitizo juu ya uelewa wa simu za mfumo na vichwa vya nafasi ya mtumiaji, na vile vile miingiliano kuu ya kernel ya ndani, kama vile jedwali. file_operations. Uendeshaji wa faili hutoa kanuni ya "kila kitu ni faili", na kuifanya iwe ya kufurahisha sana kudhibiti. C kernel chanzo faili kwenye saraka ya kiwango cha juu fs/ wasilisha utekelezaji wa mifumo ya faili pepe, ambayo ni safu ya kanga ambayo hutoa utangamano mpana na rahisi kati ya mifumo maarufu ya faili na vifaa vya kuhifadhi. Kuunganisha na kuweka kuwekelea kupitia nafasi za majina za Linux ni uchawi wa VFS unaofanya uundaji wa vyombo vya kusoma pekee na mifumo ya faili ya mizizi iwezekanavyo. Ikijumuishwa na uchunguzi wa msimbo wa chanzo, zana ya msingi ya eBPF na kiolesura chake bcc
kufanya uchunguzi wa msingi kuwa rahisi zaidi kuliko hapo awali.
Marafiki, andika, nakala hii ilikuwa muhimu kwako? Labda una maoni au maoni yoyote? Na wale ambao wana nia ya kozi ya Msimamizi wa Linux wanaalikwa , ambayo itafanyika Aprili 18.
Chanzo: mapenzi.com