Hallo almal, ons deel die tweede deel van die publikasie "Virtuele lêerstelsels in Linux: hoekom is dit nodig en hoe werk dit?" Jy kan die eerste deel lees . Laat ons jou daaraan herinner dat hierdie reeks publikasies tyd is om saam te val met die bekendstelling van 'n nuwe stroom op die kursus , wat baie gou begin.
Hoe om VFS te monitor met eBPF- en bcc-instrumente
Die maklikste manier om te verstaan hoe die kern op lêers werk sysfs is om dit in die praktyk te sien, en die maklikste manier om ARM64 te kyk, is om eBPF te gebruik. eBPF (kort vir Berkeley Packet Filter) bestaan uit 'n virtuele masjien wat inloop , wat bevoorregte gebruikers kan versoek (query) vanaf die opdragreël. Die kernbronne vertel die leser wat die kern kan doen; om die eBPF-nutsgoed op 'n gelaaide stelsel te laat loop, wys wat die kern eintlik doen.
Gelukkig is dit redelik maklik om eBPF te begin gebruik met behulp van gereedskap , wat beskikbaar is as pakkette vanaf die algemene verspreiding en in detail gedokumenteer . Gereedskap bcc is Python-skrifte met klein invoegings van C-kode, wat beteken dat enigiemand wat met albei tale vertroud is, dit maklik kan verander. IN bcc/tools Daar is 80 Python-skrifte, wat beteken dat 'n ontwikkelaar of stelseladministrateur heel waarskynlik iets sal kan kies wat geskik is om die probleem op te los.
Om ten minste 'n oppervlakkige idee te kry van watter werk VFS'e op 'n lopende stelsel doen, probeer vfscount of vfsstat. Dit sal wys, kom ons sê, dat dosyne oproepe vfs_open() en "sy vriende" gebeur letterlik elke sekonde.
vfsstat.pyis 'n Python-skrif met C-kode-insetsels wat eenvoudig VFS-funksie-oproepe tel.
Kom ons gee 'n meer onbenullige voorbeeld en kyk wat gebeur wanneer ons 'n USB-flash drive in 'n rekenaar plaas en die stelsel dit bespeur.
Deur eBPF te gebruik, kan jy sien wat in gebeur
/syswanneer 'n USB-flash drive ingesit is. 'n Eenvoudige en komplekse voorbeeld word hier getoon.
In die voorbeeld hierbo getoon, bcc hulpmiddel druk 'n boodskap wanneer die opdrag uitgevoer word sysfs_create_files(). Ons sien dit sysfs_create_files() is van stapel gestuur met behulp van kworker stroom in reaksie op die feit dat die flash drive ingevoeg is, maar watter lêer is geskep? Die tweede voorbeeld toon die krag van eBPF. Hier trace.py Druk 'n kern terugspoor (-K opsie) en die naam van die lêer wat geskep is sysfs_create_files(). Enkelstelling-invoeging is C-kode wat 'n maklik herkenbare formaatstring insluit wat verskaf word deur die Python-skrip wat LLVM laat loop net-betyds samesteller. Dit stel hierdie reël saam en voer dit uit in 'n virtuele masjien binne die kern. Volledige funksie handtekening sysfs_create_files () moet in die tweede opdrag gereproduseer word sodat die formaatstring na een van die parameters kan verwys. Foute in hierdie stuk C-kode lei tot herkenbare foute van die C-samesteller. Byvoorbeeld, as die -l parameter weggelaat word, sal jy "Failed to compile BPF text" sien. Ontwikkelaars wat vertroud is met C en Python sal die gereedskap vind bcc maklik om uit te brei en te verander.
Wanneer die USB-stasie ingesit word, sal die kern-terugspoor wys dat PID 7711 'n draad is kworkerwat die lêer geskep het «events» в sysfs. Gevolglik is die oproep van sysfs_remove_files() sal wys dat die verwydering van die skyf daartoe gelei het dat die lêer uitgevee is events, wat ooreenstem met die algemene konsep van verwysingtelling. Terselfdertyd, kyk sysfs_create_link () met eBPF terwyl die USB-stasie ingesit word, sal wys dat ten minste 48 simboliese skakels geskep is.
So wat is die punt van die gebeurtenislêer? Gebruik Vir soek , wys wat dit veroorsaak disk_add_events (), en óf "media_change"Of "eject_request" kan in 'n gebeurtenislêer aangeteken word. Hier stel die kernbloklaag gebruikersruimte in kennis dat 'n "skyf" verskyn en uitgeskiet het. Let op hoe insiggewend hierdie navorsingsmetode is deur 'n USB-stasie in te plaas, in vergelyking met om te probeer uitvind hoe dinge suiwer uit die bron werk.
Leesalleen-wortellêerstelsels aktiveer ingebedde toestelle
Natuurlik skakel niemand die bediener of hul rekenaar af deur die prop uit die sok te trek nie. Maar hoekom? Dit is omdat gemonteerde lêerstelsels op fisiese stoortoestelle dalk vertraagde skryfwerk het, en die datastrukture wat hul toestand aanteken, mag dalk nie met skryfwerk na die berging gesinchroniseer word nie. Wanneer dit gebeur, moet stelseleienaars wag tot die volgende selflaai om die nut te begin. fsck filesystem-recovery en, in die ergste geval, die verlies van data.
Ons weet egter almal dat baie IoT-toestelle, sowel as routers, termostate en motors, nou Linux bestuur. Baie van hierdie toestelle het min tot geen gebruikerskoppelvlak nie, en daar is geen manier om dit "skoon" af te skakel nie. Stel jou voor om 'n motor met 'n dooie battery te begin wanneer die krag na die beheereenheid is gedurig op en af spring. Hoe is dit dat die stelsel boots sonder 'n lang fsckwanneer begin die enjin uiteindelik loop? En die antwoord is eenvoudig. Ingebedde toestelle maak staat op die wortellêerstelsel (verkorte ro-rootfs (leesalleen wortel lêerstelsel)).
ro-rootfs bied baie voordele wat minder voor die hand liggend is as egtheid. Een voordeel is dat malware nie kan skryf nie /usr of /lib, as geen Linux-proses daar kan skryf nie. Nog een is dat 'n grootliks onveranderlike lêerstelsel van kritieke belang is vir veldondersteuning van afgeleë toestelle, aangesien ondersteuningspersoneel staatmaak op plaaslike stelsels wat nominaal identies is aan die veldstelsels. Miskien is die belangrikste (maar ook mees verraderlike) voordeel dat ro-rootfs ontwikkelaars dwing om te besluit watter stelselvoorwerpe onveranderlik sal wees in die ontwerpstadium van die stelsel. Om met ro-rootfs te werk kan ongemaklik en pynlik wees, aangesien konstante veranderlikes dikwels in programmeertale voorkom, maar die voordele daarvan regverdig maklik die bykomende bokoste.
skepping rootfs Leesalleen verg ekstra moeite vir ingebedde ontwikkelaars, en dit is waar VFS in die prentjie kom. Linux vereis dat lêers in is /var skryfbaar was, en daarbenewens sal baie gewilde toepassings wat ingebedde stelsels hardloop, probeer om konfigurasie te skep dot-files в $HOME. Een oplossing vir konfigurasielêers in die tuisgids is gewoonlik om dit vooraf te genereer en in te bou rootfs. Vir /var Een moontlike benadering is om dit op 'n aparte skryfbare partisie te monteer, terwyl / gemonteerde leesalleen. Nog 'n gewilde alternatief is om bind- of oorlegmonterings te gebruik.
Koppelbare en stapelbare monterings, hul gebruik deur houers
Opdrag uitvoering man mount is die beste manier om te leer oor bindbare en oorlegbare monterings, wat ontwikkelaars en stelseladministrateurs die vermoë gee om 'n lêerstelsel in een pad te skep en dit dan bloot te stel aan toepassings in 'n ander. Vir ingebedde stelsels beteken dit die vermoë om lêers in te stoor /var op 'n leesalleen-flash drive, maar 'n oorleg- of koppelbare monteerpad vanaf tmpfs в /var wanneer dit gelaai word, sal dit toepassings toelaat om notas daar te skryf (scrawl). Die volgende keer wat jy die veranderinge aanskakel na /var verlore sal gaan. 'n Oorlegmontering skep 'n vereniging tussen tmpfs en die onderliggende lêerstelsel en laat jou toe om skynbare veranderinge aan bestaande lêers in ro-tootf terwyl 'n bindbare berg nuwes leeg kan maak tmpfs dopgehou sigbaar as skryfbaar in ro-rootfs maniere. Terwyl overlayfs dit is die regte een (proper) lêerstelsel tipe, bindbare berg is geïmplementeer in .
Gebaseer op die beskrywing van die oorleg en koppelbare berg, is niemand daaroor verbaas nie hulle word aktief gebruik. Kom ons kyk wat gebeur wanneer ons gebruik om die houer met behulp van die instrument te laat loop mountsnoop van bcc.
oproep system-nspawn begin die houer terwyl dit loop mountsnoop.py.
Kom ons kyk wat gebeur het:
bekendstelling mountsnoop terwyl die houer besig is om te "selflaai", wys dat die houer se looptyd baie afhanklik is van die berging wat gekoppel word (Slegs die begin van die lang uitvoer word gewys).
Hier systemd-nspawn verskaf geselekteerde lêers in procfs и sysfs gasheer na houer as paaie daarheen rootfs. Behalwe MS_BIND vlag wat die bindende berging opstel, sommige ander vlae op die berg definieer die verhouding tussen veranderinge aan die gasheer- en houernaamruimtes. Byvoorbeeld, 'n gekoppelde berg kan óf veranderinge na oorslaan /proc и /sys in die houer, of versteek hulle na gelang van die oproep.
Gevolgtrekking
Om die innerlike werking van Linux te verstaan, kan na 'n onmoontlike taak lyk, aangesien die kern self 'n groot hoeveelheid kode bevat, terwyl Linux-gebruikersruimtetoepassings en stelseloproepkoppelvlakke in C-biblioteke, soos bv. glibc. Een manier om vordering te maak, is om die bronkode van een kernsubstelsel te lees, met die klem op die begrip van stelseloproepe en gebruikersspasieopskrifte, sowel as die belangrikste interne kernkoppelvlakke, soos tabel file_operations. Lêerbewerkings verskaf die "alles is 'n lêer"-beginsel, wat dit besonder aangenaam maak om te bestuur. C kernbronlêers in die topvlakgids fs/ bied 'n implementering van virtuele lêerstelsels aan, wat 'n omhullaag is wat breë en relatief eenvoudige versoenbaarheid tussen gewilde lêerstelsels en bergingstoestelle bied. Koppeling en oorlegmontering via Linux-naamruimtes is die magie van VFS wat die skep van leesalleen-houers en wortellêerstelsels moontlik maak. Gekombineer met 'n ondersoek van die bronkode, die eBPF-kerninstrument en sy koppelvlak bcc
maak kernverkenning makliker as ooit.
Vriende, skryf, was hierdie artikel nuttig vir jou? Het jy dalk enige opmerkings of opmerkings? En diegene wat belangstel in die Linux Administrateur kursus word uitgenooi na , wat op 18 April sal plaasvind.
Bron: will.com