Tere kõigile, jagame teiega teise osa postitusest „Virtuaalsed failisüsteemid Linuxis: miks need on vajalikud ja kuidas need töötavad?“ Esimese osa saab lugeda . Tuletame meelde, et see postituste seeria on pühendatud uue kursuse , mis algab peagi.
Kuidas jälgida VFS-i eBPF-i ja bcc vahendite abil
Lihtsaim viis mõista, kuidas tuum opereerib failidega sysfs – on seda praktikas jälgida ning kõige lihtsam viis ARM64 jälgimiseks on kasutada eBPF-d. eBPF (Berkeley Packet Filter lühend) koosneb virtuaalsest masinast, mis töötab , mida privileegidega kasutajad saavad pärida (query) käsurealt. Tuuma allikakoodid ütlevad lugejale, mida tuum saab teha; eBPF-i vahendite käitamine koormatud süsteemis näitab, mida tuum tegelikult teeb.
Õnneks on eBPF-i kasutuselevõtt tõeliselt lihtne bcc , mis on saadaval paketina üldisest jaotusest ja on põhjalikult dokumenteeritud . Vahendid bcc on Python’i skriptid, millel on väikesed C koodilõigud, see tähendab, et igaühel, kes tunneb mõlemat keelt, on lihtne neid kohandada. ccc bcc/tools on 80 Python’i skripti, nii et tõenäoliselt leiab arendaja või süsteemiadministraator endale sobiva lahenduse.
Kuna tahate pinnapealselt mõista, millist tööd VFS käivitatud süsteemis teeb, proovige vfscount või vfsstat. See näitab, et eeldatavalt toimuvad kümned vfs_open() ja tema sõbrad kutsuvad üles praktiliselt iga sekundi tagant.
vfsstat.pyon Python’i skript, millel on C koodialamoodulid, mis lihtsalt loendavad VFS funktsioonikutsed.
Toome välja lihtsama näite ja vaatame, mis juhtub, kui sisestame USB-mälupulga arvutisse ja süsteem tuvastab selle.
eBPF abil saab näha, mis juhtub
/sys, kui USB-mälupulk on sisse sisestatud. Siin on esitatud lihtne ja keeruline näide.
Ühes ülaltoodud näites bcc vahend prindib sõnumi, kui käivitatakse käsk sysfs_create_files(). Näeme, et sysfs_create_files() oli käivitatud kworker puhvri vastuseks sellele, et mälupulk oli sisestatud, aga milline fail selle käigus loodi? Teine näide näitab eBPF'i kogu jõudu. Siin trace.py väljastab tuuma jälgimise (kernel backtrace) (valik -K) ja faili nime, mis on loodud sysfs_create_files(). Üksikute avalduste sisestamine on C-kood, mis sisaldab kergesti äratuntavat formaadistringi, mida pakub Pythoni skript, mis käivitab LLVM just-in-time kompilaator. See string kompileeritakse ja täidetakse tuuma sees virtuaalses masinas. Funktsiooni täielik signatuur sysfs_create_files() peab olema teise käsu järgi reprodutseeritud, et formaadistring saaks viidata ühele parameetrist. Vigade olemasolu selles C-koodi fragmentis toob kaasa tuntavad C-kompilaatori vead. Näiteks, kui parameeter -l on vahele jäetud, näete "Failed to compile BPF text." Arendajad, kes tunnevad C-d ja Pythonit hästi, leiavad tööriistad bcc lihtsateks laiendamiseks ja muutmiseks.
Kui USB-mähi on ühendatud, näitab tuuma jälgimine, et PID 7711 on voog kworker, mis lõi faili "events" ja sysfs. Vastavalt sellele, kutsega sysfs_remove_files() näitab, et mähi eemaldamine viis faili eemaldamiseni events, mis vastab viidatud lugemisotsustamise kontseptsioonile. Samas, vaadates sysfs_create_link() eBPF-i juures USB-mähi ühendamisel näitab, et on loodud vähemalt 48 sümboolset linki.
Mis siis on faili events mõte? Kasutades otsimiseks , näitab see, et ta kutsub disk_add_events(), ja kas "media_change", või või "eject_request"
võivad olla salvestatud sündmuste faili. Siin tuuma plokkkiht teavitab userspace'i "disk" ilmumisest ja eemaldamisest. Pange tähele, kui informatiivne on see uurimismeetod USB-mähi ühendamise näitel võrreldes katsetega mõista, kuidas kõik töötab ainult lähtekoodidest.
Ainult lugemiseks mõeldud juurfailisüsteemid muudavad sisseehitatud seadmed võimalikuks. Muidugi ei lülita keegi teenust või oma arvutit välja, tõmmates pistiku seinast välja. Aga miks? Kõik see, et füüsiliste salvestusseadmete peal olevad kinnitatud failisüsteemid võivad sisaldada edasi lükatud kirjeid ja andmestruktuurid, mis salvestavad nende olekud, ei pruugi sünkroniseeruda salvestusseadme kirjetega. Kui see juhtub, peavad süsteemi omanikud ootama järgmise laadimisega, et käivitada utiliiti fsck filesystem-recovery and, in the worst case, lose data.
Siiski, kõik me teame, et paljud IoT seadmed, samuti ruuterid, termostaadid ja autod töötavad nüüd Linuxi all. Paljudel neist seadmetest pole praktiliselt kasutajaliidest ning nende "puhtalt" väljalülitamine ei ole võimalik. Kujutage ette, et teie auto käivitub tühja akuga, kui juhtseade on alati üles ja alla. Kuidas süsteem siis käivitub ilma pika fsck, kui mootor lõpuks tööle hakkab? Vastus on lihtne. Sisetooted toetuvad juurkataloogile (lühendatult ro-rootfs (read-only root fileystem)).
ro-rootfs pakuvad palju eeliseid, mis on vähem ilmsed kui autentsus. Üks eelis on see, et pahavara ei saa kirjutada /usr või /lib, kuna ükski Linuxi protsess ei saa sinna kirjutada. Teine on see, et suuresti muutmatu failisüsteem on kriitilise tähtsusega kaugseade toetamiseks, kuna abipersonal kasutab kohalikke süsteeme, mis on nominaalselt identsed kohapealsete süsteemidega. Võib-olla on kõige olulisem (aga ka kõige petlikum) eelis see, et ro-rootfs sunnib arendajaid otsustama, millised süsteemi objektid jäävad muutumatuks, juba süsteemi projekteerimise etapis. Töö ro-rootfs-iga võib olla ebamugav ja valulik, nagu see sageli on const muutujate puhul programmeerimiskeeltes, kuid nende eelised katavad hõlpsasti lisakulud.
Meetodi loomine rootfs ainult lugemiseks nõuab lisaponnistusi sissejuhatavate süsteemide arendajatelt, ja siin tulebki mängu VFS. Linux nõuab, et failid oleksid /var kirjutamiseks kergesti kättesaadavad, ning paljud populaarsed rakendused, mis käivitavad sissejuhatavaid süsteeme, püüavad tavaliselt luua konfiguratsiooni dot-failid ja $HOME. Üks lahendus kodukausta konfiguratsioonifailide jaoks on tavaliselt nende eelnevalt genereerimine ja koostamine rootfs. Üheks võimaluseks on see, et seda montaaž on eraldi osasse, mis on kirjutamiseks kergesti kätessäadav, samas kui enda /var mount on ainult lugemiseks. Teine populaarne alternatiiv on kasutada siduvaid või kattuvaid mount'e (bind or overlay mounts). / installitakse ainult lugemiseks. Teine populaarne alternatiiv on sidumismountide või pealismountide (bind or overlay mounts) kasutamine.
Seotud ja kattuvad montaažid, nende kasutamine konteinerites
Käsu täitmine man mount – parim viis teada saada seotud ja kattuvatest montaažidest, mis annavad arendajatele ja süsteemiadministraatoritele võimaluse luua failisüsteem ühes teed, ning seejärel anda see rakendustele teises. Sisseehitatud süsteemide jaoks tähendab see võimalust hoida faile /var ainult lugemise õigusega välkmäluseadmest, kuid kattuva või seondumise montaaži tee kaudu tmpfs ja /var käivitamisel võimaldab rakendustel sinna märkmeid kirjutada (scrawl). Järgmisel sisselülitamisel jääb muudatused /var kaotsi. Kattuv montaaž loob ühinemise tmpfs ja alloleva failisüsteemi vahel ning lubab teha näiliselt muudatusi olemasolevates failides ro-tootf kui seotud montaaž võib teha uusi tühi tmpfs kaustad nähtavaks kirjutamiseks ro-rootfs tee põhimõttena. Samas kui overlayfs on õige (proper) failisüsteemi tüüp, on seotud montaaž rakendatud .
Üksikasjaliku nakke- ja seondumise montaaži põhjal ei ole üllatav, et kasutavad neid aktiivselt. Vaatame, mis toimub, kui kasutame konteineri käivitamiseks, kasutades tööriista mountsnoop alates bcc.
Kutsumine system-nspawn käivitab konteineri töötamise ajal mountsnoop.py.
Vaatame, mis välja tuli:
Käivitamine mountsnoop „konteineri laadimise” ajal näitab, et konteineri töö keskkond sõltub tugevalt seondumisest (Kuvatakse ainult pika väljundi algus).
Siin systemd-nspawn toob valitud failid procfs ja sysfs külalistelt konteinerisse teedena rootfs. Lisaks MS_BIND lipule, mis seab seondumise montaaži, määravad mõned teised lipud monteeritavas süsteemis suhte muutuste vahel, mis toimuvad külaliste nimederuumis ja konteineris. Näiteks võib seondumine kas jätta muutused /proc ja /sys konteinerisse või varjata neid sõltuvalt kutsest.
Kokkuvõte
Linuxi sisemise struktuuri mõistmine võib tunduda ületamatu ülesandena, sest ise kerneli sees on tohutu hulgal koodi, kõrvale jättes Linuxi kasutajaliidese rakendused ja süsteemi kutsumise liidesed C keeles, nagu glibc. Üks viis edusamme saavutada on lugeda ühe alamsüsteemi lähtekoodi, keskendudes süsteemikõnede ja kasutajaruumi suunatud peade arusaamisele ning tuumade peamistele sisemistele liidestele, näiteks tabelile. file_operations. Failitegevused järgivad põhimõtet „kõik on fail”, seetõttu on nende haldamine eriti nauditav. Tuuma lähtefailid keeles C asuvad ülemise katalooge. fs/ esindavad virtuaalsete failisüsteemide rakendust, mis on kaitsekihina, pakkudes laialdast ja suhteliselt lihtsat ühilduvust populaarsete failisüsteemide ja salvestusseadmitega. Lingitud ja ülekattumiseks mountimine Linuxi nimede kaudu on VFS-i maagia, mis võimaldab luua konteinerite ja ainult lugemiseks mõeldud juurkatalooge. Koos lähtekoodi uurimisega, tuuma eBPF ja selle liidesed bcc
muudavad tuuma uurimise lihtsamaks kui kunagi varem.
Sõbrad, palun kirjutage, kas see artikkel oli teile kasulik? Võib-olla on teil mõni kommentaar või tähelepanek? Need, keda huvitab kursus „Linuxi administraator”, ootame teid , mis toimub 18. aprillil.
Allikas: habr.com
