Hej alla, vi delar den andra delen av publikationen "Virtuella filsystem i Linux: varför behövs de och hur fungerar de?" Du kan läsa den första delen . Låt oss påminna dig om att denna serie av publikationer är tidsinställd att sammanfalla med lanseringen av en ny stream på kursen , som börjar mycket snart.
Hur man övervakar VFS med hjälp av eBPF och bcc-verktyg
Det enklaste sättet att förstå hur kärnan fungerar på filer sysfs är att se det i praktiken, och det enklaste sättet att se ARM64 är att använda eBPF. eBPF (förkortning för Berkeley Packet Filter) består av en virtuell maskin som körs in , som privilegierade användare kan begära (query) från kommandoraden. Kärnkällorna talar om för läsaren vad kärnan kan göra; att köra eBPF-verktygen på ett laddat system visar vad kärnan faktiskt gör.
Lyckligtvis är det ganska enkelt att komma igång med eBPF med hjälp av verktyg , som är tillgängliga som paket från den allmänna distributionen och dokumenterat i detalj . Verktyg bcc är Python-skript med små insättningar av C-kod, vilket innebär att alla som är bekanta med båda språken enkelt kan ändra dem. I bcc/tools Det finns 80 Python-skript, vilket innebär att en utvecklare eller systemadministratör med största sannolikhet kommer att kunna välja något som passar för att lösa problemet.
För att få åtminstone en ytlig uppfattning om vad VFS:er gör på ett körande system, försök vfscount eller vfsstat. Detta kommer att visa, låt oss säga, att dussintals samtal vfs_open() och "hans vänner" händer bokstavligen varje sekund.
vfsstat.pyär ett Python-skript med C-kodinlägg som helt enkelt räknar VFS-funktionsanrop.
Låt oss ge ett mer trivialt exempel och se vad som händer när vi sätter in ett USB-minne i en dator och systemet upptäcker det.
Med eBPF kan du se vad som händer i
/sysnär ett USB-minne är isatt. Ett enkelt och komplext exempel visas här.
I exemplet ovan, bcc инструмент skriver ut ett meddelande när kommandot körs sysfs_create_files(). Vi ser det sysfs_create_files() lanserades med hjälp av kworker stream som svar på det faktum att flashenheten sattes in, men vilken fil skapades? Det andra exemplet visar kraften i eBPF. Här trace.py Skriver ut en kärnspårning (alternativet-K) och namnet på filen som skapades sysfs_create_files(). Infogning av en enstaka påstående är C-kod som innehåller en lätt igenkännlig formatsträng som tillhandahålls av Python-skriptet som kör LLVM just-in-time kompilator. Den kompilerar den här raden och kör den i en virtuell maskin inuti kärnan. Full funktionssignatur sysfs_create_files () måste återges i det andra kommandot så att formatsträngen kan referera till en av parametrarna. Fel i denna del av C-koden resulterar i igenkännbara fel från C-kompilatorn. Till exempel, om parametern -l utelämnas, kommer du att se "Det gick inte att kompilera BPF-text." Utvecklare som är bekanta med C och Python kommer att hitta verktygen bcc lätt att bygga ut och ändra.
När USB-enheten är insatt visar kärnans bakåtspårning att PID 7711 är en tråd kworkersom skapade filen «events» в sysfs. Följaktligen har samtalet från sysfs_remove_files() kommer att visa att borttagning av enheten resulterade i att filen raderades events, vilket motsvarar det allmänna begreppet referensräkning. Samtidigt tittar sysfs_create_link () med eBPF när du sätter i USB-enheten kommer att visa att minst 48 symboliska länkar har skapats.
Så vad är poängen med händelsefilen? Användande För sökning , visar vad det orsakar disk_add_events (), och antingen "media_change"Eller "eject_request" kan spelas in i en händelsefil. Här informerar kärnblockslagret användarutrymme om att en "disk" har dykt upp och matats ut. Notera hur informativ denna forskningsmetod är genom att sätta in en USB-enhet, jämfört med att försöka ta reda på hur saker fungerar rent från källan.
Lässkyddade rotfilsystem aktiverar inbäddade enheter
Naturligtvis stänger ingen av servern eller sin dator genom att dra ut kontakten ur uttaget. Men varför? Detta beror på att monterade filsystem på fysiska lagringsenheter kan ha fördröjda skrivningar, och de datastrukturer som registrerar deras tillstånd kanske inte är synkroniserade med skrivningar till lagringen. När detta händer måste systemägare vänta tills nästa start för att starta verktyget. fsck filesystem-recovery och i värsta fall förlora data.
Men vi vet alla att många IoT-enheter, såväl som routrar, termostater och bilar, nu kör Linux. Många av dessa enheter har lite eller inget användargränssnitt, och det finns inget sätt att stänga av dem "rent". Föreställ dig att starta en bil med urladdat batteri när strömmen till styrenheten finns ständigt hoppa upp och ner. Hur kommer det sig att systemet startar utan en lång fscknär börjar motorn äntligen gå? Och svaret är enkelt. Inbäddade enheter är beroende av rotfilsystemet (förkortat ro-rootfs (skrivskyddat rotfilsystem)).
ro-rootfs erbjuder många fördelar som är mindre uppenbara än äkthet. En fördel är att skadlig programvara inte kan skriva till /usr eller /lib, om ingen Linux-process kan skriva där. En annan är att ett i stort sett oföränderligt filsystem är avgörande för fältstöd av fjärrenheter, eftersom supportpersonal förlitar sig på lokala system som nominellt är identiska med fältsystemen. Den kanske viktigaste (men också mest lömska) fördelen är att ro-rootfs tvingar utvecklare att bestämma vilka systemobjekt som kommer att vara oföränderliga vid designstadiet av systemet. Att arbeta med ro-rootfs kan vara besvärligt och smärtsamt, eftersom konstvariabler ofta finns i programmeringsspråk, men deras fördelar motiverar lätt den extra omkostnaden.
skapande rootfs Skrivskyddad kräver lite extra ansträngning för inbäddade utvecklare, och det är här VFS kommer in i bilden. Linux kräver att filer finns i /var var skrivbara, och dessutom kommer många populära applikationer som kör inbäddade system att försöka skapa konfiguration dot-files в $HOME. En lösning för konfigurationsfiler i hemkatalogen är vanligtvis att förgenerera och bygga in dem rootfs. För /var En möjlig metod är att montera den på en separat skrivbar partition, medan / monterad skrivskyddad. Ett annat populärt alternativ är att använda bind- eller överlagringsfästen.
Länkbara och stapelbara fästen, deras användning av containrar
Kommandoexekvering man mount är det bästa sättet att lära sig om bindbara och överlagringsbara monteringar, som ger utvecklare och systemadministratörer möjligheten att skapa ett filsystem på en väg och sedan exponera det för applikationer i en annan. För inbäddade system innebär detta möjligheten att lagra filer i /var på en skrivskyddad flashenhet, men en överlagrings- eller länkbar monteringsväg från tmpfs в /var när den laddas kommer det att tillåta applikationer att skriva anteckningar där (scrawla). Nästa gång du slår på ändringarna till /var kommer att förloras. Ett överläggsfäste skapar en förening mellan tmpfs och det underliggande filsystemet och låter dig göra skenbara ändringar i befintliga filer i ro-tootf medan ett bindbart fäste kan göra nya tomma tmpfs mappar som är synliga som skrivbara i ro-rootfs sätt. Medan overlayfs det här är den rätta (proper) filsystemstyp, bindbar montering implementeras i .
Baserat på beskrivningen av överlägget och det länkbara fästet är ingen förvånad över det de används aktivt. Låt oss se vad som händer när vi använder för att köra behållaren med verktyget mountsnoop från bcc.
samtal system-nspawn startar behållaren medan den körs mountsnoop.py.
Låt oss se vad som hände:
Запуск mountsnoop medan containern "startar" visar att containerns körtid är starkt beroende av monteringen som är länkad (endast början av den långa utgången visas).
Här systemd-nspawn tillhandahåller valda filer i procfs и sysfs värd till behållare som vägar till den rootfs... Förutom MS_BIND flaggan som ställer in bindningsmonteringen, vissa andra flaggor på monteringen definierar förhållandet mellan ändringar av värden och behållarens namnutrymmen. Till exempel kan en länkad montering antingen hoppa över ändringar till /proc и /sys i behållaren, eller dölj dem beroende på samtalet.
Slutsats
Att förstå Linuxs inre funktioner kan tyckas vara en omöjlig uppgift, eftersom själva kärnan innehåller en enorm mängd kod, om man lämnar Linux-användarutrymmesapplikationer och systemanropsgränssnitt i C-bibliotek som t.ex. glibc. Ett sätt att göra framsteg är att läsa källkoden för ett kärndelsystem, med tonvikt på att förstå systemanrop och användarutrymmesrubriker, såväl som de viktigaste interna kärngränssnitten, såsom tabeller file_operations. Filoperationer ger principen "allt är en fil", vilket gör dem särskilt trevliga att hantera. C-kärnan källfiler i toppnivåkatalogen fs/ presentera en implementering av virtuella filsystem, som är ett omslagsskikt som ger bred och relativt enkel kompatibilitet mellan populära filsystem och lagringsenheter. Länkning och överlagringsmontering via Linux-namnområden är magin med VFS som gör det möjligt att skapa skrivskyddade behållare och rotfilsystem. Kombinerat med en granskning av källkoden, kärnverktyget eBPF och dess gränssnitt bcc
gör kärnutforskning enklare än någonsin.
Vänner, skriv, var den här artikeln användbar för dig? Kanske har du några kommentarer eller kommentarer? Och de som är intresserade av kursen Linux Administrator är inbjudna till , som äger rum den 18 april.
Källa: will.com