Hei alle sammen, vi deler den andre delen av publikasjonen "Virtuelle filsystemer i Linux: hvorfor trengs de og hvordan fungerer de?" Du kan lese den første delen . La oss minne deg på at denne serien med publikasjoner er tidsbestemt til å falle sammen med lanseringen av en ny strøm på kurset , som starter veldig snart.
Hvordan overvåke VFS ved hjelp av eBPF og bcc-verktøy
Den enkleste måten å forstå hvordan kjernen fungerer på filer sysfs er å se det i praksis, og den enkleste måten å se ARM64 på er å bruke eBPF. eBPF (forkortelse for Berkeley Packet Filter) består av en virtuell maskin som kjører inn , som privilegerte brukere kan be om (query) fra kommandolinjen. Kjernekildene forteller leseren hva kjernen kan gjøre; kjører eBPF-verktøyene på et lastet system viser hva kjernen faktisk gjør.
Heldigvis er det ganske enkelt å komme i gang med eBPF ved hjelp av verktøy , som er tilgjengelige som pakker fra den generelle distribusjonen og dokumentert i detalj . Verktøy bcc er Python-skript med små innsettinger av C-kode, noe som betyr at alle som er kjent med begge språkene enkelt kan endre dem. I bcc/tools Det er 80 Python-skript, noe som betyr at mest sannsynlig vil en utvikler eller systemadministrator kunne velge noe som passer for å løse problemet.
For å få minst en overfladisk ide om hva VFS-er gjør på et kjørende system, prøv vfscount eller vfsstat. Dette vil vise, la oss si, at dusinvis av samtaler vfs_open() og "vennene hans" skjer bokstavelig talt hvert sekund.
vfsstat.pyer et Python-skript med C-kodeinnlegg som ganske enkelt teller VFS-funksjonskall.
La oss gi et mer trivielt eksempel og se hva som skjer når vi setter inn en USB-flash-stasjon i en datamaskin og systemet oppdager det.
Ved å bruke eBPF kan du se hva som skjer i
/sysnår en USB-flash-stasjon er satt inn. Et enkelt og komplekst eksempel vises her.
I eksemplet vist ovenfor, bcc инструмент skriver ut en melding når kommandoen kjøres sysfs_create_files(). Det ser vi sysfs_create_files() ble lansert ved hjelp av kworker stream som svar på det faktum at flash-stasjonen ble satt inn, men hvilken fil ble opprettet? Det andre eksemplet viser kraften til eBPF. Her trace.py Skriver ut en kjernebaksporing (-K-alternativet) og navnet på filen som ble opprettet sysfs_create_files(). Enkeltsetningsinnsetting er C-kode som inkluderer en lett gjenkjennelig formatstreng levert av Python-skriptet som kjører LLVM just-in-time kompilator. Den kompilerer denne linjen og kjører den i en virtuell maskin inne i kjernen. Full funksjonssignatur sysfs_create_files () må reproduseres i den andre kommandoen slik at formatstrengen kan referere til en av parameterne. Feil i denne delen av C-koden resulterer i gjenkjennelige feil fra C-kompilatoren. For eksempel, hvis parameteren -l er utelatt, vil du se "Kunnet ikke kompilere BPF-tekst." Utviklere som er kjent med C og Python vil finne verktøyene bcc lett å utvide og endre.
Når USB-stasjonen er satt inn, vil kjernens tilbakesporing vise at PID 7711 er en tråd kworkersom opprettet filen «events» в sysfs. Følgelig ringer fra sysfs_remove_files() vil vise at fjerning av stasjonen førte til at filen ble slettet events, som tilsvarer det generelle begrepet referansetelling. Samtidig visning sysfs_create_link () med eBPF mens du setter inn USB-stasjonen vil vise at minst 48 symbolske lenker er opprettet.
Så hva er poenget med hendelsesfilen? Bruk For søk , viser hva det forårsaker disk_add_events (), og enten "media_change"Eller "eject_request" kan tas opp i en hendelsesfil. Her informerer kjerneblokklaget brukerområdet om at en "disk" har dukket opp og kastet ut. Legg merke til hvor informativ denne forskningsmetoden er ved å sette inn en USB-stasjon, sammenlignet med å prøve å finne ut hvordan ting fungerer rent fra kilden.
Skrivebeskyttede rotfilsystemer aktiverer innebygde enheter
Selvfølgelig er det ingen som slår av serveren eller datamaskinen ved å trekke støpselet ut av stikkontakten. Men hvorfor? Dette er fordi monterte filsystemer på fysiske lagringsenheter kan ha forsinket skriving, og datastrukturene som registrerer tilstanden deres er kanskje ikke synkronisert med skrivinger til lagringen. Når dette skjer, må systemeiere vente til neste oppstart for å starte verktøyet. fsck filesystem-recovery og i verste fall miste data.
Imidlertid vet vi alle at mange IoT-enheter, så vel som rutere, termostater og biler, nå kjører Linux. Mange av disse enhetene har lite eller ingen brukergrensesnitt, og det er ingen måte å slå dem av "rent". Tenk deg å starte en bil med tomt batteri når strømmen til kontrollenheten er hele tiden hopper opp og ned. Hvordan har det seg at systemet starter uten lang tid fscknår begynner motoren endelig å gå? Og svaret er enkelt. Innebygde enheter er avhengige av rotfilsystemet (forkortet ro-rootfs (skrivebeskyttet rotfilsystem)).
ro-rootfs tilbyr mange fordeler som er mindre åpenbare enn autentisitet. En fordel er at skadelig programvare ikke kan skrive til /usr eller /lib, hvis ingen Linux-prosess kan skrive der. En annen er at et stort sett uforanderlig filsystem er kritisk for feltstøtte for eksterne enheter, siden støttepersonell er avhengig av lokale systemer som nominelt er identiske med feltsystemene. Den kanskje viktigste (men også mest lumske) fordelen er at ro-rootfs tvinger utviklere til å bestemme hvilke systemobjekter som vil være uforanderlige på designstadiet av systemet. Å jobbe med ro-rootfs kan være vanskelig og smertefullt, ettersom konstantvariabler ofte er i programmeringsspråk, men fordelene deres rettferdiggjør lett den ekstra overheaden.
opprettelse rootfs Skrivebeskyttet krever litt ekstra innsats for innebygde utviklere, og det er her VFS kommer inn i bildet. Linux krever at filene er i /var var skrivbare, og i tillegg vil mange populære applikasjoner som kjører innebygde systemer forsøke å lage konfigurasjon dot-files в $HOME. En løsning for konfigurasjonsfiler i hjemmekatalogen er vanligvis å forhåndsgenerere og bygge dem inn rootfs. Til /var En mulig tilnærming er å montere den på en separat skrivbar partisjon, mens / montert skrivebeskyttet. Et annet populært alternativ er å bruke binde- eller overleggsfester.
Koblebare og stablebare fester, deres bruk av containere
Kommandoutførelse man mount er den beste måten å lære om bindbare og overleggbare monteringer, som gir utviklere og systemadministratorer muligheten til å lage et filsystem i én bane og deretter eksponere det for applikasjoner i en annen. For innebygde systemer betyr dette muligheten til å lagre filer i /var på en skrivebeskyttet flash-stasjon, men en overlegg eller koblingsbar monteringsbane fra tmpfs в /var når du laster, vil det tillate programmer å skrive notater der (scrawl). Neste gang du slår på endringene til /var Vil gå tapt. Et overleggsfeste skaper en forening mellom tmpfs og det underliggende filsystemet og lar deg gjøre tilsynelatende endringer i eksisterende filer i ro-tootf mens et bindbart feste kan gjøre nye tomme tmpfs mapper som er synlige som skrivbare i ro-rootfs måter. Samtidig som overlayfs dette er den rette (proper) filsystemtype, bindbar montering er implementert i .
Basert på beskrivelsen av overlegget og koblingsbart feste, er ingen overrasket over det de brukes aktivt. La oss se hva som skjer når vi bruker for å kjøre beholderen ved hjelp av verktøyet mountsnoop fra bcc.
samtale system-nspawn starter beholderen mens den kjører mountsnoop.py.
La oss se hva som skjedde:
lanseringen mountsnoop mens containeren "starter" viser at containerens kjøretid er svært avhengig av monteringen som er koblet (kun begynnelsen av den lange utgangen vises).
Her systemd-nspawn gir utvalgte filer i procfs и sysfs vert til container som stier til den rootfs. I tillegg MS_BIND flagget som setter opp bindingsmonteringen, noen andre flagg på monteringen definerer forholdet mellom endringer i verts- og containernavneområdene. For eksempel kan en koblet montering enten hoppe over endringer til /proc и /sys inn i beholderen, eller skjul dem avhengig av samtalen.
Konklusjon
Å forstå den indre funksjonen til Linux kan virke som en umulig oppgave, siden selve kjernen inneholder en enorm mengde kode, og ser bort fra Linux-brukerplassapplikasjoner og systemanropsgrensesnitt i C-biblioteker som f.eks. glibc. En måte å gjøre fremskritt på er å lese kildekoden til ett kjernedelsystem, med vekt på å forstå systemanrop og brukerromsoverskrifter, så vel som de viktigste interne kjernegrensesnittene, for eksempel tabeller file_operations. Filoperasjoner gir "alt er en fil"-prinsippet, noe som gjør dem spesielt morsomme å administrere. C-kjernekildefiler i toppnivåkatalogen fs/ presentere en implementering av virtuelle filsystemer, som er et omslagslag som gir bred og relativt enkel kompatibilitet mellom populære filsystemer og lagringsenheter. Kobling og overleggsmontering via Linux-navneområder er magien med VFS som gjør det mulig å lage skrivebeskyttede beholdere og rotfilsystemer. Kombinert med en undersøkelse av kildekoden, eBPF-kjerneverktøyet og dets grensesnitt bcc
gjør kjerneutforskning enklere enn noen gang.
Venner, skriv, var denne artikkelen nyttig for deg? Kanskje du har noen kommentarer eller kommentarer? Og de som er interessert i Linux Administrator-kurset inviteres til , som finner sted 18. april.
Kilde: www.habr.com