Virtuální souborové systémy v Linuxu: proč jsou potřebné a jak fungují? Část 2

Ahoj všichni, sdílíme s vámi druhou část publikace „Virtuální souborové systémy v Linuxu: proč jsou potřeba a jak fungují?“ První díl si můžete přečíst zde. Připomeňme, že tato série publikací je načasována tak, aby se shodovala se spuštěním nového streamu na hřišti "Správce Linuxu", která začíná velmi brzy.

Jak monitorovat VFS pomocí nástrojů eBPF a bcc

Nejjednodušší způsob, jak pochopit, jak jádro funguje se soubory sysfs je vidět v praxi a nejjednodušší způsob, jak sledovat ARM64, je použít eBPF. eBPF (zkratka pro Berkeley Packet Filter) se skládá z běžícího virtuálního stroje jádro, o které mohou privilegovaní uživatelé požádat (query) z příkazového řádku. Zdroje jádra sdělují čtenáři, co jádro umí; spuštění nástrojů eBPF na načteném systému ukazuje, co jádro skutečně dělá.

Virtuální souborové systémy v Linuxu: proč jsou potřebné a jak fungují? Část 2

Začít používat eBPF je naštěstí s pomocí nástrojů docela snadné Bcc, které jsou dostupné jako balíčky z obecné distribuce Linux a podrobně zdokumentováno Bernard Gregg. Nástroje bcc jsou Python skripty s malými vkládáními kódu C, což znamená, že kdokoli zná oba jazyky, je může snadno upravit. V bcc/tools Existuje 80 skriptů Python, což znamená, že s největší pravděpodobností si vývojář nebo správce systému bude moci vybrat něco vhodného pro řešení problému.
Chcete-li získat alespoň povrchní představu o tom, jakou práci dělají VFS na běžícím systému, zkuste to vfscount nebo vfsstat. To ukáže, řekněme, desítky hovorů vfs_open() a „jeho přátelé“ se dějí doslova každou sekundu.

Virtuální souborové systémy v Linuxu: proč jsou potřebné a jak fungují? Část 2

vfsstat.py je Python skript s vloženým kódem C, který jednoduše počítá volání funkcí VFS.

Uveďme si triviálnější příklad a podívejme se, co se stane, když vložíme USB flash disk do počítače a systém to detekuje.

Virtuální souborové systémy v Linuxu: proč jsou potřebné a jak fungují? Část 2

Pomocí eBPF můžete vidět, co se děje /syspo vložení USB flash disku. Zde je uveden jednoduchý a složitý příklad.

Ve výše uvedeném příkladu bcc инструмент trace.py vypíše zprávu při spuštění příkazu sysfs_create_files(). To vidíme sysfs_create_files() byl spuštěn pomocí kworker stream v reakci na to, že byl vložen flash disk, ale jaký soubor byl vytvořen? Druhý příklad ukazuje sílu eBPF. Tady trace.py Vytiskne zpětné trasování jádra (volba -K) a název souboru, který byl vytvořen sysfs_create_files(). Vložení jednoho příkazu je kód C, který obsahuje snadno rozpoznatelný formátovací řetězec poskytovaný skriptem Python, který spouští LLVM kompilátor just-in-time. Zkompiluje tento řádek a spustí jej ve virtuálním stroji uvnitř jádra. Plně funkční podpis sysfs_create_files () musí být reprodukován ve druhém příkazu, aby formátovací řetězec mohl odkazovat na jeden z parametrů. Chyby v této části kódu C mají za následek rozpoznatelné chyby z kompilátoru C. Pokud je například vynechán parametr -l, zobrazí se "Nepodařilo se zkompilovat text BPF." Vývojáři, kteří znají C a Python, nástroje najdou bcc snadno rozšířit a změnit.

Když je USB disk vložen, zpětné sledování jádra ukáže, že PID 7711 je vlákno kworkerkterá vytvořila soubor «events» в sysfs. V souladu s tím hovor od sysfs_remove_files() zobrazí, že odebrání jednotky vedlo ke smazání souboru events, což odpovídá obecné koncepci počítání referencí. Zároveň prohlížení sysfs_create_link () s eBPF při vložení USB disku ukáže, že bylo vytvořeno alespoň 48 symbolických odkazů.

Jaký je tedy smysl souboru událostí? Používání cscope Pro vyhledávání __device_add_disk(), ukazuje, co způsobuje disk_add_events (), a buď "media_change"Nebo "eject_request" lze zaznamenat do souboru události. Zde vrstva jaderného bloku informuje uživatelský prostor, že se objevil a vysunul „disk“. Všimněte si, jak informativní je tato výzkumná metoda vložením USB disku ve srovnání se snahou zjistit, jak věci fungují čistě ze zdroje.

Kořenové systémy souborů pouze pro čtení umožňují vestavěná zařízení

Nikdo samozřejmě nevypíná server ani svůj počítač vytažením zástrčky ze zásuvky. Ale proč? Je to proto, že připojené souborové systémy na fyzických úložných zařízeních mohou mít zpožděné zápisy a datové struktury, které zaznamenávají jejich stav, nemusí být synchronizovány se zápisy do úložiště. Když k tomu dojde, majitelé systému musí se spuštěním nástroje počkat do dalšího spuštění. fsck filesystem-recovery a v nejhorším případě i ztrátu dat.

Všichni však víme, že na mnoha zařízeních IoT, stejně jako na routerech, termostatech a autech, nyní běží Linux. Mnoho z těchto zařízení má malé nebo žádné uživatelské rozhraní a neexistuje žádný způsob, jak je „na čistotu“ vypnout. Představte si, že nastartujete auto s vybitou baterií, když je napájení řídicí jednotky zapnuté Linux neustále skákat nahoru a dolů. Jak to, že systém nabootuje bez dlouhého fsckkdy se motor konečně rozběhne? A odpověď je jednoduchá. Vestavěná zařízení spoléhají na kořenový souborový systém pouze na čtení (zkráceně ro-rootfs (kořenový souborový systém pouze pro čtení)).

ro-rootfs nabízejí mnoho výhod, které jsou méně zřejmé než autenticita. Jednou z výhod je, že malware nemůže zapisovat /usr nebo /lib, pokud tam žádný linuxový proces nemůže zapisovat. Další je, že do značné míry neměnný souborový systém je kritický pro podporu vzdálených zařízení v terénu, protože podpůrný personál spoléhá na místní systémy, které jsou nominálně identické se systémy v terénu. Snad nejdůležitější (ale také nejzáludnější) výhodou je, že ro-rootfs nutí vývojáře rozhodnout, které systémové objekty budou neměnné ve fázi návrhu systému. Práce s ro-rootfs může být nepohodlná a bolestivá, protože proměnné const jsou často v programovacích jazycích, ale jejich výhody snadno ospravedlní další režii.

tvorba rootfs Pouze pro čtení vyžaduje od vestavěných vývojářů určité úsilí navíc a zde přichází na řadu VFS. Linux vyžaduje, aby byly soubory in /var byly zapisovatelné a navíc se mnoho populárních aplikací, které provozují vestavěné systémy, pokusí vytvořit konfiguraci dot-files в $HOME. Jedním z řešení pro konfigurační soubory v domovském adresáři je obvykle jejich předgenerování a zabudování rootfs. Pro /var Jedním z možných přístupů je připojit jej na samostatný zapisovatelný oddíl / namontované pouze pro čtení. Další oblíbenou alternativou je použití spojovacích nebo překryvných držáků.

Spojitelné a stohovatelné držáky, jejich použití u kontejnerů

Provedení příkazu man mount je nejlepší způsob, jak se dozvědět o připojeních s možností vazby a překrytí, která umožňují vývojářům a správcům systému vytvořit souborový systém v jedné cestě a poté jej vystavit aplikacím v jiné. Pro vestavěné systémy to znamená možnost ukládat soubory do /var na flash disku pouze pro čtení, ale z překryvné nebo propojitelné cesty připojení tmpfs в /var při načítání umožní aplikacím psát si tam poznámky (čmárat). Při příštím zapnutí změn na /var bude ztraceno. Překryvná montáž vytváří spojení mezi nimi tmpfs a základní souborový systém a umožňuje vám provádět zdánlivé změny existujících souborů v ro-tootf zatímco svázatelný držák může uvolnit nové tmpfs složky viditelné jako zapisovatelné ro-rootfs způsoby. Zatímco overlayfs tohle je ten pravý (proper) typ souborového systému, ve kterém je implementováno připojitelné připojení jmenný prostor VFS.

Na základě popisu překryvu a propojitelného držáku se tomu nikdo nediví Linuxové kontejnery jsou aktivně využívány. Podívejme se, co se stane, když použijeme systemd-nspawn ke spuštění kontejneru pomocí nástroje mountsnoop z bcc.

Výzva system-nspawn spustí kontejner za chodu mountsnoop.py.

Uvidíme, co se stane:

Spusťte mountsnoop zatímco se kontejner "bootuje", ukazuje, že běh kontejneru je vysoce závislý na připojeném připojení (je zobrazen pouze začátek dlouhého výstupu).

Zde systemd-nspawn poskytuje vybrané soubory v procfs и sysfs hostitele do kontejneru jako cesty k němu rootfs. kromě MS_BIND příznak, který nastavuje připojení vazby, některé další příznaky na připojení definují vztah mezi změnami jmenných prostorů hostitele a kontejneru. Například připojené připojení může buď přeskočit změny /proc и /sys do kontejneru, nebo je skryjte v závislosti na volání.

Závěr

Pochopení vnitřního fungování Linuxu se může zdát jako nemožný úkol, protože samotné jádro obsahuje obrovské množství kódu, pomineme-li aplikace v uživatelském prostoru Linuxu a rozhraní systémových volání v knihovnách C, jako je např. glibc. Jedním ze způsobů, jak dosáhnout pokroku, je číst zdrojový kód jednoho jaderného subsystému s důrazem na pochopení systémových volání a hlaviček v uživatelském prostoru, stejně jako hlavních interních rozhraní jádra, jako je tabulka file_operations. Operace se soubory poskytují princip „všechno je soubor“, díky čemuž je jejich správa obzvláště příjemná. Zdrojové soubory jádra C v adresáři nejvyšší úrovně fs/ představují implementaci virtuálních souborových systémů, které jsou obalovou vrstvou, která poskytuje širokou a relativně jednoduchou kompatibilitu mezi oblíbenými souborovými systémy a úložnými zařízeními. Propojování a připojování překryvů prostřednictvím jmenných prostorů Linuxu je kouzlo VFS, které umožňuje vytvářet kontejnery pouze pro čtení a kořenové souborové systémy. V kombinaci se zkoumáním zdrojového kódu, základního nástroje eBPF a jeho rozhraní bcc
takže průzkum jádra je jednodušší než kdy jindy.

Přátelé, pište, byl pro vás tento článek užitečný? Možná máte nějaké připomínky nebo připomínky? A zájemci o kurz Linux Administrator jsou zváni Den otevřených dveří, která se uskuteční 18. dubna.

První díl.

Zdroj: www.habr.com

Přidat komentář