Hej allihopa, vi delar med er den andra delen av publikationen "Virtuella filsystem i Linux: зачем они нужны и как они работают?» Первую часть можно прочитать . Låt oss påminna dig om att denna serie av publikationer är tidsinställd att sammanfalla med lanseringen av en ny kursström , som börjar mycket snart.
Hur man övervakar VFS med eBPF och bcc-verktyg
Det enklaste sättet att förstå hur kärnan hanterar filer sysfs – är att se det i praktiken, och det enklaste sättet att observera 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-verktyg på ett uppstartat system avslöjar vad kärnan faktiskt gör.
Lyckligtvis är det ganska enkelt att komma igång med eBPF med verktyg , som är tillgängliga som paket från den allmänna distributionen och dokumenterat i detalj . Verktyg bcc – det här är Python-skript med små insatser 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 betyder att en utvecklare eller systemadministratör med största sannolikhet kommer att kunna hitta något som passar för att lösa ett problem.
För att få åtminstone en översiktlig uppfattning om vilken typ av arbete VFS gör i 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– detta är ett Python-skript med C-kodinlägg som helt enkelt räknar VFS-funktionsanrop.
Låt oss ta 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
/sys, nä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(). Det ser vi 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 den fulla kraften hos eBPF. Här trace.py skriver ut kärnans bakåtspårning (alternativ -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 ett Python-skript 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 detta C-kodfragment resulterar i igenkännliga C-kompilatorfel. Till exempel, om parametern -l saknas, kommer du att se "Det gick inte att kompilera BPF-text." Utvecklare som är bekanta med C och Python kommer att hitta verktyg bcc lätt att bygga ut och ändra.
När USB-minnet är isatt kommer kärnans bakåtspårning att visa att PID 7711 är tråden kworker, som skapade filen «events» в sysfs. Följaktligen är uppmaningen sysfs_remove_files() kommer att visa att borttagning av enheten resulterade i att filen raderades events, vilket överensstämmer med det allmänna begreppet referensräkning. Samtidigt tittar sysfs_create_link () med eBPF när du sätter i ett USB-minne kommer det 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 att det orsakar disk_add_events (), och antingen "media_change"Eller "eject_request" kan skrivas till händelsefilen. Här informerar kärnblockslagret användarutrymmet om utseendet och borttagningen av "disken". Lägg märke till hur informativ denna undersökningsmetod är baserad på att sätta i ett USB-minne, jämfört med att försöka ta reda på hur saker och ting fungerar utifrån källkoden enbart.
Läsbara rotfilsystem gör inbäddade enheter möjliga
Naturligtvis stänger ingen av en server 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 posterna i lagringen. När detta händer måste systemägare vänta tills nästa start för att köra verktyget. fsck filesystem-recovery och i värsta fall förlora data.
Тем не менее, все мы знаем, что многие IoT устройства, а также маршрутизаторы, термостаты и автомобили теперь работают под управлением Linux. Многие из этих устройств практически не имеют пользовательского интерфейса, и нет никакого способа выключить их «чисто». Представьте себе запуск автомобиля с разряженной батареей, когда питание управляющего устройства на ständigt hoppa upp och ner. Hur kommer det sig att systemet startar utan en lång tid fsck, när börjar motorn äntligen fungera? 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 äkta. En av fördelarna är att skadlig programvara inte kan skriva till /usr eller /lib, если ни один процесс Linux не может туда писать. Другое заключается в том, что в значительной степени неизменяемая файловая система имеет решающее значение для полевой поддержки удаленных устройств, поскольку вспомогательный персонал пользуется локальными системами, которые номинально идентичны системам на местах. Возможно, самым важным (но и самым коварным) преимуществом является то, что ro-rootfs заставляет разработчиков решать, какие системные объекты будут неизменными, еще на этапе проектирования системы. Работа с ro-rootfs может быть неудобной и болезненной, как это часто бывает с переменными const в языках программирования, но их преимущества легко окупают дополнительные накладные расходы.
skapande rootfs только для чтения требует некоторых дополнительных усилий для разработчиков встраиваемых систем, и именно здесь на сцену выходит VFS. Linux требует, чтобы файлы в /var var skrivbara, och dessutom kommer många populära applikationer som körs på 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 dem 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.
Bindbara och stapelbara fästen och deras användning av containrar
Utför kommandot man mount – det bästa sättet att lära sig om länkbara och staplingsbara monteringar, som gör det möjligt för utvecklare och systemadministratörer 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 ett överlägg eller länkfäste av sökvägen från tmpfs в /var När du laddar kommer det att tillåta applikationer att skriva anteckningar där (scrawla). Nästa gång du slår på ändringarna in /var kommer att gå förlorad. Ett överläggsfäste skapar en förening mellan tmpfs och det underliggande filsystemet och låter dig göra ändringar i befintliga filer i ro-tootf medan ett länkbart fäste kan göra nya tomma tmpfs mappar som är synliga som skrivbara i ro-rootfs vägar. Medan overlayfs detta är korrekt (proper) filsystemstyp, länkbar montering implementeras i .
Baserat på beskrivningen av överlägg och länkfästen ä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 hjälp av verktyget mountsnoop från bcc.
samtal system-nspawn startar behållaren under drift mountsnoop.py.
Låt oss se vad som hände:
Запуск mountsnoop under container "boot" visar att containerns körtid är starkt beroende av det bindbara fästet (endast början av den långa utgången visas).
Här systemd-nspawn tillhandahåller de valda filerna procfs и sysfs värd i container som vägar i den rootfs... Förutom MS_BIND flaggan som ställer in bindningsmonteringen, vissa andra flaggor i monteringen bestämmer förhållandet mellan ändringar i värd- och containernamnrymden. Till exempel kan en bindmontering antingen hoppa över ändringar till /proc и /sys i en container, eller dölj dem beroende på samtalet.
Slutsats
Понимание внутреннего устройства Linux может казаться невыполнимой задачей, так как само ядро содержит гигантское количество кода, оставляя в стороне приложения пользовательского пространства Linux и интерфейсы системных вызовов в библиотеках на языке C, таких как 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 rubriker som möter användarutrymmet, såväl som de viktigaste interna kärngränssnitten, såsom tabellen file_operations. Filoperationer tillämpar principen "allt är en fil", vilket gör dem särskilt trevliga att hantera. Kernel C-källfiler i katalogen på översta nivån fs/ представляют реализацию виртуальных файловых систем, которые являются слоем оболочки, обеспечивающим широкую и относительно простую совместимость популярных файловых систем и устройств хранения. Монтирование со связыванием и накладыванием через пространства имен Linux — это волшебство VFS, которое делает возможным создание контейнеров и корневых файловых систем только для чтения. В сочетании с изучением исходного кода, средство ядра eBPF и его интерфейс bcc
gör kärnutforskning enklare än någonsin.
Друзья, напишите была ли эта статья полезной для вас? Возможно у вас есть какие-то комментарии или замечания? А тех, кому интересен курс «Администратор Linux», приглашаем на , som äger rum den 18 april.
Källa: will.com
