Hei kaikki, jaamme kanssanne julkaisun "Virtuaaliset tiedostojärjestelmät Linuxissa: miksi niitä tarvitaan ja miten ne toimivat" toisen osan. Voit lukea ensimmäisen osan . Muistutetaan, että tämä julkaisusarja on ajoitettu samaan aikaan, kun kurssilla julkaistaan uusi stream , joka alkaa hyvin pian.
Kuinka seurata VFS:ää eBPF- ja bcc-työkaluilla
Helpoin tapa ymmärtää kuinka ydin toimii tiedostoissa sysfs on nähdä se käytännössä, ja helpoin tapa katsella ARM64:ää on käyttää eBPF:ää. eBPF (lyhenne sanoista Berkeley Packet Filter) koostuu virtuaalikoneesta, joka on käynnissä , jota etuoikeutetut käyttäjät voivat pyytää (query) komentoriviltä. Ytimen lähteet kertovat lukijalle, mitä ydin voi tehdä; eBPF-työkalujen suorittaminen ladatussa järjestelmässä näyttää, mitä ydin todella tekee.
Onneksi eBPF:n käytön aloittaminen on melko helppoa työkalujen avulla , jotka ovat saatavilla paketteina yleisestä jakelusta ja dokumentoitu yksityiskohtaisesti . Työkalut bcc ovat Python-skriptejä, joissa on pieniä C-koodin lisäyksiä, mikä tarkoittaa, että jokainen, joka tuntee molemmat kielet, voi helposti muokata niitä. SISÄÄN bcc/tools Python-skriptejä on 80, mikä tarkoittaa, että todennäköisesti kehittäjä tai järjestelmänvalvoja pystyy valitsemaan jotain sopivaa ongelman ratkaisemiseen.
Yritä saada ainakin pintapuolinen käsitys siitä, mitä VFS:t tekevät käynnissä olevassa järjestelmässä vfscount tai vfsstat. Tämä näyttää, sanotaanko, että kymmeniä puheluita vfs_open() ja "hänen ystävänsä" tapahtuu kirjaimellisesti joka sekunti.
vfsstat.pyon Python-skripti, jossa on C-koodilisäyksiä, joka yksinkertaisesti laskee VFS-funktiokutsut.
Otetaan triviaalimpi esimerkki ja katsotaan mitä tapahtuu, kun asetamme USB-muistitikun tietokoneeseen ja järjestelmä havaitsee sen.
eBPF:n avulla näet, mitä siinä tapahtuu
/syskun USB-muistitikku on asetettu. Tässä on yksinkertainen ja monimutkainen esimerkki.
Yllä näytetyssä esimerkissä bcc työkalu tulostaa viestin, kun komento suoritetaan sysfs_create_files(). Näemme sen sysfs_create_files() käynnistettiin käyttämällä kworker stream vastauksena siihen, että flash-asema asetettiin, mutta mikä tiedosto luotiin? Toinen esimerkki näyttää eBPF:n tehon. Tässä trace.py Tulostaa ytimen paluujäljityksen (-K-vaihtoehto) ja luodun tiedoston nimen sysfs_create_files(). Yhden lauseen lisäys on C-koodi, joka sisältää helposti tunnistettavan muotomerkkijonon, jonka LLVM:ää suorittava Python-skripti tarjoaa juuri-in-time-kääntäjä. Se kääntää tämän rivin ja suorittaa sen virtuaalikoneessa ytimen sisällä. Täysi toimintojen allekirjoitus sysfs_create_files () on toistettava toisessa komennossa, jotta muotomerkkijono voi viitata johonkin parametreista. Virheet tässä C-koodin osassa johtavat tunnistettavissa oleviin virheisiin C-kääntäjästä. Jos esimerkiksi -l-parametri jätetään pois, näet ilmoituksen "BPF-tekstin kääntäminen epäonnistui." C:n ja Pythonin tuntevat kehittäjät löytävät työkalut bcc helppo laajentaa ja muuttaa.
Kun USB-asema asetetaan paikalleen, ytimen paluujäljitys näyttää, että PID 7711 on säiettä kworkerjoka loi tiedoston «events» в sysfs. Vastaavasti puhelu sysfs_remove_files() näyttää, että aseman poistaminen johti tiedoston poistamiseen events, joka vastaa viitelaskennan yleistä käsitettä. Samalla katsomassa sysfs_create_link () eBPF:llä, kun asetat USB-aseman, näyttää, että vähintään 48 symbolista linkkiä on luotu.
Joten mitä järkeä tapahtumatiedostolla on? Käyttö Hakua varten , näyttää mitä se aiheuttaa disk_add_events (), ja joko "media_change"Tai "eject_request" voidaan tallentaa tapahtumatiedostoon. Tässä ytimen lohkokerros ilmoittaa käyttäjätilalle, että "levy" on ilmestynyt ja poistettu. Huomaa, kuinka informatiivinen tämä tutkimusmenetelmä on liittämällä USB-asema, verrattuna siihen, että yrität selvittää, miten asiat toimivat puhtaasti lähteestä.
Vain luku -olevissa juuritiedostojärjestelmät mahdollistavat sulautetut laitteet
Kukaan ei tietenkään sammuta palvelinta tai tietokonettaan vetämällä pistoke pistorasiasta. Mutta miksi? Tämä johtuu siitä, että liitetyissä tiedostojärjestelmissä fyysisille tallennuslaitteille saattaa olla viivästynyt kirjoitus, ja tietorakenteet, jotka tallentavat niiden tilan, eivät välttämättä ole synkronoitu muistiin kirjoitusten kanssa. Kun näin tapahtuu, järjestelmän omistajien on odotettava seuraavaan käynnistykseen asti apuohjelman käynnistäminen. fsck filesystem-recovery ja pahimmassa tapauksessa tietojen menettäminen.
Tiedämme kuitenkin, että monet IoT-laitteet sekä reitittimet, termostaatit ja autot käyttävät nyt Linuxia. Monilla näistä laitteista on vähän tai ei ollenkaan käyttöliittymää, eikä niitä voi sammuttaa "puhtaasti". Kuvittele käynnistää auto, jonka akku on tyhjä, kun ohjausyksikön virta on päällä hyppää jatkuvasti ylös ja alas. Miten järjestelmä käynnistyy ilman pitkää aikaa fsckmilloin moottori vihdoin käynnistyy? Ja vastaus on yksinkertainen. Sulautetut laitteet perustuvat juuritiedostojärjestelmään (lyhennettynä ro-rootfs (vain luku -juuritiedostojärjestelmä)).
ro-rootfs tarjoavat monia etuja, jotka ovat vähemmän ilmeisiä kuin aitous. Yksi etu on, että haittaohjelmat eivät voi kirjoittaa niihin /usr tai /lib, jos mikään Linux-prosessi ei voi kirjoittaa sinne. Toinen on se, että pitkälti muuttumaton tiedostojärjestelmä on kriittinen etälaitteiden kenttätuelle, koska tukihenkilöstö luottaa paikallisiin järjestelmiin, jotka ovat nimellisesti identtisiä kenttäjärjestelmien kanssa. Ehkä tärkein (mutta myös salakavalin) etu on se, että ro-rootfs pakottaa kehittäjät päättämään, mitkä järjestelmäobjektit ovat muuttumattomia järjestelmän suunnitteluvaiheessa. Ro-rootf:ien kanssa työskentely voi olla hankalaa ja tuskallista, koska const-muuttujat ovat usein ohjelmointikielissä, mutta niiden edut oikeuttavat helposti ylimääräiset lisäkustannukset.
luominen rootfs Vain luku vaatii ylimääräistä vaivaa sulautetuilta kehittäjiltä, ja tässä VFS tulee kuvaan. Linux edellyttää, että tiedostot ovat sisällä /var oli kirjoitettavissa, ja lisäksi monet sulautettuja järjestelmiä käyttävät suositut sovellukset yrittävät luoda määrityksiä dot-files в $HOME. Yksi ratkaisu kotihakemiston konfigurointitiedostoille on yleensä luoda ja rakentaa ne valmiiksi rootfs. Voit /var Yksi mahdollinen tapa on asentaa se erilliseen kirjoitettavaan osioon / asennettu vain luku -tilassa. Toinen suosittu vaihtoehto on käyttää side- tai overlay-kiinnikkeitä.
Yhdistettävät ja pinottavat kiinnikkeet, niiden käyttö konteissa
Komennon suoritus man mount on paras tapa oppia sitovista ja päällekkäisistä liitännöistä, jotka antavat kehittäjille ja järjestelmänvalvojille mahdollisuuden luoda tiedostojärjestelmän yhdessä polussa ja paljastaa sen sitten toisen polun sovelluksille. Sulautetuissa järjestelmissä tämä tarkoittaa mahdollisuutta tallentaa tiedostoja /var vain luku -muistitikulla, mutta peittokuva tai linkitettävä asennuspolku tmpfs в /var latauksen aikana se sallii sovellusten kirjoittaa sinne muistiinpanoja (scrawl). Kun seuraavan kerran otat muutokset käyttöön /var menetetään. Päällystyskiinnitys luo liitoksen välille tmpfs ja taustalla olevaan tiedostojärjestelmään ja voit tehdä näennäisiä muutoksia olemassa oleviin tiedostoihin ro-tootf kun taas sidottava teline voi tyhjentää uudet tmpfs kansiot näkyvät kirjoitettavina ro-rootfs tavoilla. Sillä aikaa overlayfs tämä on oikea (proper) tiedostojärjestelmätyyppi, sitova asennus on toteutettu .
Peitteen ja linkitettävän kiinnikkeen kuvauksen perusteella kukaan ei ole yllättynyt siitä niitä käytetään aktiivisesti. Katsotaan mitä tapahtuu, kun käytämme suorittaaksesi säiliön työkalun avulla mountsnoop alkaen bcc.
puhelu system-nspawn käynnistää säiliön ajon aikana mountsnoop.py.
Katsotaan, mitä tapahtui:
Запуск mountsnoop Säilön käynnistyessä osoittaa, että säilön suoritusaika riippuu suuresti linkitetystä liittimestä (vain pitkän lähdön alku näkyy).
Täällä systemd-nspawn tarjoaa valitut tiedostot procfs и sysfs isäntä konttiin poluina siihen rootfs. poikkeuksen MS_BIND lippu, joka määrittää sitovan liitännän, jotkin muut liitännän liput määrittävät isäntä- ja säilön nimitilojen muutosten välisen suhteen. Esimerkiksi linkitetty kiinnitys voi joko ohittaa muutokset /proc и /sys säilöön tai piilota ne puhelun mukaan.
Johtopäätös
Linuxin sisäisten toimintojen ymmärtäminen voi tuntua mahdottomalta tehtävältä, koska ydin itsessään sisältää valtavan määrän koodia, jättäen sivuun Linuxin käyttäjätilan sovellukset ja järjestelmäkutsuliitännät C-kirjastoissa, kuten esim. glibc. Yksi tapa edistyä on lukea yhden ytimen alijärjestelmän lähdekoodi painottaen järjestelmäkutsujen ja käyttäjätilan otsikoiden sekä tärkeimpien sisäisten ytimen käyttöliittymien, kuten taulukon ymmärtämistä. file_operations. Tiedostotoiminnot tarjoavat "kaikki on tiedostoa" -periaatteen, mikä tekee niiden hallinnasta erityisen nautinnollisen. C-ytimen lähdetiedostot ylätason hakemistossa fs/ esittelee virtuaalisten tiedostojärjestelmien toteutuksen, joka on käärekerros, joka tarjoaa laajan ja suhteellisen yksinkertaisen yhteensopivuuden suosittujen tiedostojärjestelmien ja tallennuslaitteiden välillä. Linkittäminen ja päällekkäisyys Linux-nimiavaruuksien kautta on VFS:n taika, joka mahdollistaa vain luku -säilöjen ja juuritiedostojärjestelmien luomisen. Yhdessä lähdekoodin, eBPF-ydintyökalun ja sen käyttöliittymän tutkimiseen bcc
tekee ydintutkimuksesta helpompaa kuin koskaan.
Ystävät, kirjoita, oliko tämä artikkeli hyödyllinen sinulle? Ehkä sinulla on kommentteja tai huomautuksia? Ja Linux Administrator -kurssista kiinnostuneet ovat tervetulleita , joka järjestetään 18. huhtikuuta.
Lähde: will.com