Hallo almal, ons deel met julle die tweede deel van die publikasie "Virtuele lêerstelsels in LinuxWaarom is hulle nodig en hoe werk hulle? Die eerste deel kan gelees word . 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 op ... werk. LinuxBaie van hierdie toestelle het feitlik geen gebruikerskoppelvlak nie, en daar is geen manier om hulle skoon af te skakel nie. Stel jou voor jy begin 'n motor met 'n dooie battery wanneer die krag na die beheertoestel afgesny word. 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, indien geen proses Linux kan nie daarna skryf nie. Nog een is dat 'n grootliks onveranderlike lêerstelsel noodsaaklik is vir veldondersteuning van afgeleë toestelle, aangesien ondersteuningspersoneel plaaslike stelsels gebruik wat nominaal identies is aan die stelsels op die perseel. Miskien die belangrikste (maar ook mees verraderlike) voordeel is dat ro-rootfs ontwikkelaars dwing om vroeg in die stelselontwerp te besluit watter stelselobjekte onveranderlik sal wees. Om met ro-rootfs te werk, kan ongemaklik en pynlik wees, soos dikwels die geval is met konstante veranderlikes in programmeertale, maar die voordele daarvan weeg swaarder as die bykomende oorhoofse koste.
skepping rootfs Leesalleen-funksionaliteit vereis ekstra moeite vir ingebedde ontwikkelaars, en dit is waar VFS ter sprake kom. Linux vereis dat lêers in /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
Verstaan die interne struktuur Linux mag dalk soos 'n onmoontlike taak lyk, aangesien die kern self 'n groot hoeveelheid kode bevat, wat gebruikersruimte-toepassings opsy sit Linux en stelseloproep-koppelvlakke in C-biblioteke soos 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/ verteenwoordig 'n implementering van virtuele lêerstelsels, wat 'n omhulsellaag is wat breë en relatief eenvoudige versoenbaarheid tussen gewilde lêerstelsels en stoortoestelle bied. Montering met skakeling en oorleg via naamruimtes Linux — is die towerkrag van VFS wat dit moontlik maak om houers en leesalleen-wortellêerstelsels te skep. Gekombineer met 'n studie van die bronkode, die eBPF-kernhulpmiddel en sy koppelvlak bcc
maak kernverkenning makliker as ooit.
Vriende, laat weet my of hierdie artikel vir julle nuttig was. Het julle dalk enige kommentaar of voorstelle? En vir diegene wat belangstel in die "Administrateur"-kursus, Linux", ons nooi jou uit om , wat op 18 April sal plaasvind.
Bron: will.com
