Virtuaalsed failisüsteemid Linuxis: miks need on vajalikud ja kuidas need töötavad? Osa 2

Tere kõigile, jagame teiega teise osa publikatsioonist „Virtuaalsed failisüsteemid Linuxis: miks need on vajalikud ja kuidas need töötavad?“ Esimest osa saab lugeda siin. Tuletame meelde, et see publikatsioonide seeria on pühendatud uue kursuse „Linuxi administraator“, mis algab juba peagi.

Kuidas jälgida VFS-i eBPF ja bcc tööriistade abil

Lihtsaim viis mõista, kuidas tuum faile töötleb sysfs – on vaadata seda praktiliselt, ning kõige lihtsam viis ARM64 jälgimiseks on kasutada eBPF-d. eBPF (lühend Berkeley Packet Filter) koosneb virtuaalsest masinast, mis sõltub tuumast, mida privileegiga kasutajad saavad käivitada (query) käsurealt. Tuuressurged tuuma allikad informeerivad lugejat sellest, mida tuum teha saab; eBPF tööriistade käivitamine koormatud süsteemis näitab, mida tuum tegelikult teeb.

Virtuaalsed failisüsteemid Linuxis: miks need on vajalikud ja kuidas need töötavad? Osa 2

Õnneks on eBPF-i kasutamise alustamine üsna lihtne bcc tööriistade abil, bcc, mis on saadaval paketina üldises jaotuses Linux ja on põhjalikult dokumenteeritud Bernard Gregg. Tööriistad bcc on Python'is kirjutatud skriptid väikeste C-koodi tükkidega, mis tähendab, et igaüks, kes tunneb mõlemat keelt, saab neid kergesti muuta. Toodetes bcc/tools on 80 Python skripti, mis tähendab, et tõenäoliselt suudab arendaja või süsteemi administreerija leida midagi sobivat ülesande lahendamiseks.
Selleks, et saada vähemalt pinnapealne arusaam, millist tööd VFS käimasolevas süsteemis teeb, proovige vfscount või vfsstat. See näitab näiteks, et kümnete kutsungite vfs_open() ja "tema sõpradega" toimub sõna otseses mõttes iga sekundi tagant.

Virtuaalsed failisüsteemid Linuxis: miks need on vajalikud ja kuidas need töötavad? Osa 2

vfsstat.py on Python'i skript, millel on C koodi tükid, mis lihtsalt loendab VFS-i funktsioonide kutsungeni.

Toome välja lihtsama näite ja vaatame, mis juhtub, kui ühendame USB-mälupulga arvutisse ja süsteem tuvastab selle.

Virtuaalsed failisüsteemid Linuxis: miks need on vajalikud ja kuidas need töötavad? Osa 2

eBPF abil saab vaadata, mis juhtub /sys, kui USB-mälupulk on sisse lülitatud. Siin on toodud lihtne ja keeruline näide.

Ülaltoodud näites bcc tööriist trace.py väljastab sõnumi, kui käivitatakse käsk sysfs_create_files(). Näeme, et sysfs_create_files() on käivitatud kworker vooge, mis tekib vastuseks, et mälupulk on sisse pandud, kuid milline fail samal ajal loodi? Teine näide näitab eBPFi kogu võimsust. Siin trace.py toodab tuuma tagasiteed (kernel backtrace) (valik -K) ja faili nime, mis loodi sysfs_create_files(). Üheainsa avaldusena on see C-kood, mis sisaldab kergesti tuvastatavat formaatrida, mida toetab Python'i skript, mis käivitab LLVM aeg-täpsustamise kompileerija. See rida kompileeritakse ja täidetakse virtuaalmasinas tuumas. Täielik funktsiooni allkiri sysfs_create_files () peab olema teises komandos domineeritud, et formaatrida saaks viidata ühele parameetrist. Vead selles C-koodis põhjustavad tuvastatavaid C-kompilaatori vigu. Näiteks, kui parameeter -l on vahele jäetud, näete "Failed to compile BPF text." Arendajad, kes tunnevad C ja Python'it hästi, leiavad tööriistad bcc lihtsateks laiendamiseks ja muutmiseks.

Kui USB-mälupulk on sisse pandud, näitab tuuma tagasitee, et PID 7711 on see voog kworker, mis lõi faili "events" ühes sysfs. Vastavalt sellele näitab kõne sysfs_remove_files() et seadme eemaldamine viis faili eemaldamiseni events, mis järgib üldist linkide arvestamise kontseptsiooni. Samal ajal, kui vaatate sysfs_create_link() , siis EBPF-i abiga USB-mäluseadmest sisestamisel näitab, et on loodud vähemalt 48 sümboolset linki.

Mis on siis failide events mõte? Kasutades cscope otsimiseks __device_add_disk(), näitab, et see kutsub välja disk_add_events(), ja kas "media_change", või "eject_request" võivad olla salvestatud sündmuste faili. Siin tuletab tuuma plokkkiht userspace'ile teada 'ketta' olemasolust ja eemaldamisest. Pange tähele, kui informatiivne on see uurimismeetod USB-mäluseadmest sisestamisel võrreldes katsetega mõista, kuidas kõik töötab, ainult lähtekoodist.

Root failisüsteemid ainult lugemiseks muudavad sisseehitatud seadmed võimalikuks.

Muidugi, keegi ei lülita serverit või oma arvutit vooluvõrgust lahti tõmmates. Aga miks? Kõik see on tingitud sellest, et füüsiliste andmesalvestusseadmete failisüsteemidel võivad olla viivitusega kirjutised ning andmestruktuurid, mis salvestavad nende oleku, ei pruugi salvestustega sünkroniseeruda. Kui see juhtub, peavad süsteemi omanikud ootama järgmise taaskäivitamise ajal utiliidi käivitamist. fsck failisüsteemi taastamine ja halvemal juhul, kaotama andmed.

Siiski, me kõik teame, et paljud IoT seadmed, samuti ruuterid, termostaadid ja autod töötavad nüüd Linuxi peal. Paljudel neist seadmetest pole praktiliselt kasutajaliidest ja pole mingit viisi, kuidas neid "puhtalt" välja lülitada. Kujutage ette, et autot käivitatakse tühja akuga, kui toide juhtseadmest Linux kõigub pidevalt üles-alla. Kuidas on võimalik, et süsteem bootib ilma pika fsck, kui mootor lõpuks tööle hakkab? Vastus on lihtne. Integreeritud seadmed toetuvad juurfailisüsteemile ainult lugemiseks (lühendatult ro-rootfs (read-only root fileystem)).

ro-rootfs pakuvad mitmeid eeliseid, mis on vähem ilmsed kui autentsus. Üks eeliseid on see, et pahavara ei saa kirjutada /usr või /lib, kui ükski Linuxi protsess ei saa sinna kirjutada. Teine on see, et ulatuslikult muutumatu failisüsteem on hädavajalik kaugete seadmete välitugiks, kuna abipersonal kasutab kohalike süsteemide osas, mis on nominaalselt identsete süsteemide abil. Võib-olla on kõige olulisem (kuid samas salakaval) eelis see, et ro-rootfs paneb arendajad otsustama, millised süsteemi objektid jäävad muutumatuks juba enne süsteemi projekteerimise etappi. Töö ro-rootfs-iga võib olla ebamugav ja valus, nagu see sageli on const-muutujatega programmeerimiskeeltes, kuid nende eelised katavad kergesti lisakulud.

Loomine rootfs ainult lugemise jaoks vajab see sisseehitatud süsteemide arendajatelt täiendavaid jõupingutusi, ja just siin tuleb mängu VFS. Linux nõuab, et failid /var olid on saadaval, ja paljusid populaarseid rakendusi, mis töötavad sisseehitatud süsteemides, püüavad luua konfiguratsioonifile. dot-failid ühes $HOME. Üks lahendus konfiguratsioonifailide kodukaustas on nende eelneva genereerimise ja kokkupanemise kasutamine. rootfs. Selle jaoks /var üks võimalik lähenemine on monteerida see eraldi kirjutamisõigustega partitsioonile, samas kui see ise / on montaaž ainult lugemiseks. Teine populaarne alternatiiv on kasutada siduvaid või ülekandeteid (bind or overlay mounts).

Siduvad ja ülekandeteed, nende kasutamine konteinerites

Käivitades käsu man mount on parim viis teada saada sidumistest ja ülekandeteedest, mis võimaldavad arendajatel ja süsteemiadministraatoritel luua faili süsteemi ühes teed ja seejärel võimaldada seda rakendustele teises. Sisseehitatud süsteemide jaoks tähendab see võimalust hoida faile /var flash-mälupuldil, mis on ainult lugemiseks, kuid ülekandeteed või siduvad montaažid teest tmpfs ühes /var rakenduste üles laadimisel võimaldab see sinna märkmeid (scrawl) salvestada. Järgmise sisselülitamise korral muudatused /var kaovad. Ülekatte montaaž loob ühenduse tmpfs ja madalamate failisüsteemidega ning võimaldab väidetavalt olemasolevate failide muudatusi ro-tootf samal ajal kui ühendatavad montaažid võivad luua uusi tühje tmpfs kaustu nähtavaks kirjutamiseks ro-rootfs teedel. Samal ajal kui overlayfs on õige (proper) failisüsteemi tüüp, on ühendatavad montaažid teostatud VFS nimes.

Pidades silmas ülekate montaaži ja ühendatava montaaži kirjelduse järgi, ei üllata kedagi, et Linuxi konteinerid kasutavad neid aktiivselt. Vaatame, mis juhtub, kui kasutame systemd-nspawn konteineri käivitamiseks kasutades tööriista mountsnoop alates bcc.

Kutse system-nspawn käivitab konteineri töötamise ajal mountsnoop.py.

Vaatame, mis sai:

Käivita mountsnoop konteineri „laadimise” ajal näitab, et konteineri täitmisvõime sõltub tugevalt ühendatavast montaažist (kuvatakse ainult pika väljundi algus).

Siit systemd-nspawn pakub valitud faile procfs ja sysfs maja konteinerisse nagu teed rootfs. Koos MS_BIND lipuk, mis seadistab seotud montaaži, mõned teised lipukesed montaažisüsteemis määravad seose hosti ja konteineri nimede vahel toimuvate muudatustega. Näiteks võib seotud montaaž kas ignoreerida muudatusi /proc ja /sys konteineris või varjata neid olenevalt kutsest.

Kokkuvõte

Linuxi siseehituse mõistmine võib tunduda ületamatu ülesandena, kuna tuum sisaldab tohutul hulgal koodi, rääkimata Linuxi kasutusrakendustest ja süsteemitõenduse liidestest C keeles, nagu glibc. Üks viis edusamme saavutada on lugeda ühe tuuma allüksuse lähtekoodi, keskendudes süsteemitõenduste ja kasutajaruumi suunatud päiste mõistmisele, samuti põhisiseste liideste, näiteks tabeli file_operations. Failioperatsioonid järgivad põhimõtet "kõik on fail", seega on nende haldamine eriti nauditav. Tuuma lähtekood C keeles asub ülemises kataloogis fs/ esitlevad virtuaalsete failisüsteemide rakendust, mis on kihi kest, pakkudes laialdast ja suhteliselt lihtsat ühilduvust populaarsete failisüsteemide ja salvestusseadmete vahel. Lingitud ja ruumide kaudu kohandatud montaaž Linuxi nimede ruumide kaudu on see VFS maagia, mis võimaldab luua konteinerite ja ainult lugemiseks mõeldud juurfailisüsteeme. Koos lähtekoodi uurimisega, tuum eBPF ja selle liides bcc
teevad tuuma uurimise lihtsamaks kui kunagi varem.

Sõbrad, andke teada, kas see artikkel oli teid abistav? Võib-olla on teil mingeid kommentaare või märkusi? Need, keda huvitab kursus „Linuxi administraator“, on oodatud avatud uste päev, mis toimub 18. aprillil.

Esimene osa.

Allikas: habr.com

Osta usaldusväärne veebihosting DDoS kaitsega, VPS VDS serverid 🔥 Osta usaldusväärne veebihosting DDoS kaitsega, VPS VDS serverid | ProHoster