Üdvözlünk mindenkit! Megosztjuk veletek a „Virtuális fájlrendszerek Linuxban: miért van szükség rájuk és hogyan működnek” című kiadvány második részét. Az első részt olvashatjátok . Emlékeztetünk arra, hogy ezt a kiadványsorozatot úgy időzítették, hogy egybeessen egy új folyam elindításával a tanfolyamon , ami nagyon hamar kezdődik.
A VFS figyelése eBPF és Bcc eszközökkel
A legegyszerűbb módja annak, hogy megértsük, hogyan működik a kernel a fájlokon sysfs a gyakorlatban látni, és az ARM64 nézésének legegyszerűbb módja az eBPF használata. Az eBPF (a Berkeley Packet Filter rövidítése) egy befutó virtuális gépből áll , amelyet a kiváltságos felhasználók kérhetnek (query) a parancssorból. A kernelforrások megmondják az olvasónak, hogy a kernel mire képes; Az eBPF-eszközök futtatása betöltött rendszeren megmutatja, mit csinál a kernel valójában.
Szerencsére az eBPF használatának megkezdése meglehetősen egyszerű az eszközök segítségével , amelyek csomagként érhetők el az általános disztribúcióból és részletesen dokumentált . Eszközök bcc Python-szkriptek kis C-kód beillesztésekkel, ami azt jelenti, hogy bárki, aki ismeri mindkét nyelvet, könnyen módosíthatja azokat. BAN BEN bcc/tools 80 Python szkript létezik, ami azt jelenti, hogy nagy valószínűséggel egy fejlesztő vagy rendszergazda tud majd valami megfelelőt választani a probléma megoldására.
Ha legalább felületes képet szeretne kapni arról, hogy a VFS-ek milyen munkát végeznek egy futó rendszeren, próbálja ki vfscount vagy vfsstat. Ez mondjuk azt mutatja, hogy több tucat hívás vfs_open() és a „barátai” szó szerint minden másodpercben előfordulnak.
vfsstat.pyegy Python szkript C kód beillesztésekkel, amely egyszerűen számolja a VFS függvényhívásokat.
Mondjunk egy triviálisabb példát, és nézzük meg, mi történik, ha USB flash meghajtót helyezünk a számítógépbe, és a rendszer észleli.
Az eBPF segítségével láthatja, hogy mi történik
/sysamikor USB flash meghajtót helyez be. Itt egy egyszerű és összetett példa látható.
A fent látható példában bcc szerszám üzenetet nyomtat a parancs futtatásakor sysfs_create_files(). Ezt látjuk sysfs_create_files() segítségével indították el kworker stream válaszul arra, hogy behelyezték a flash meghajtót, de milyen fájl jött létre? A második példa az eBPF erejét mutatja be. Itt trace.py Kinyomtat egy kernel visszakövetést (-K opció) és a létrehozott fájl nevét sysfs_create_files(). Az egyszeri utasítás beillesztése egy C kód, amely egy könnyen felismerhető formátumú karakterláncot tartalmaz, amelyet az LLVM-et futtató Python szkript biztosít. éppen időben fordító. Ezt a sort lefordítja és a kernelen belüli virtuális gépen végrehajtja. Teljes funkciós aláírás sysfs_create_files () a második parancsban kell reprodukálni, hogy a formátum karakterlánc hivatkozhasson valamelyik paraméterre. A C kód ezen részében lévő hibák felismerhető hibákat eredményeznek a C fordítóból. Ha például az -l paramétert kihagyjuk, akkor a „BPF szöveg fordítása sikertelen” üzenet jelenik meg. A C-t és a Pythont ismerő fejlesztők megtalálják az eszközöket bcc könnyen bővíthető és változtatható.
Az USB-meghajtó behelyezésekor a kernel visszakövetése azt mutatja, hogy a PID 7711 egy szál kworkeramely létrehozta a fájlt «events» в sysfs. Ennek megfelelően a hívás a sysfs_remove_files() megmutatja, hogy a meghajtó eltávolítása a fájl törlését eredményezte events, ami megfelel a referenciaszámlálás általános fogalmának. Egyúttal nézegetni sysfs_create_link () eBPF-fel az USB-meghajtó behelyezése közben azt mutatja, hogy legalább 48 szimbolikus hivatkozás jött létre.
Tehát mi értelme az eseményfájlnak? Használat A kereséshez , megmutatja, mit okoz disk_add_events (), és bármelyik "media_change"Vagy "eject_request" eseményfájlba rögzíthető. Itt a kernelblokk réteg tájékoztatja a felhasználói teret, hogy megjelent egy "lemez" és kiadták. Jegyezze meg, mennyire informatív ez a kutatási módszer egy USB-meghajtó behelyezése ahhoz képest, hogy pusztán a forrásból próbálja kitalálni, hogyan működnek a dolgok.
A csak olvasható gyökérfájlrendszerek lehetővé teszik a beágyazott eszközöket
Természetesen senki sem kapcsolja ki a szervert vagy a számítógépét a konnektorból való kihúzással. De miért? Ennek az az oka, hogy a fizikai tárolóeszközökön lévő csatolt fájlrendszerek írási késedelmet szenvedhetnek, és előfordulhat, hogy az állapotukat rögzítő adatstruktúrák nem szinkronizálódnak a tárolóba történő írásokkal. Amikor ez megtörténik, a rendszertulajdonosoknak várniuk kell a következő rendszerindításig, hogy elindítsák a segédprogramot. fsck filesystem-recovery és legrosszabb esetben adatvesztés.
Mindannyian tudjuk azonban, hogy sok IoT-eszköz, valamint útválasztó, termosztát és autó már Linuxot futtat. Sok ilyen eszköz alig vagy egyáltalán nem rendelkezik felhasználói felülettel, és nincs mód "tisztán" kikapcsolni őket. Képzeljen el egy lemerült akkumulátorú autót, amikor a vezérlőegység áram alatt van állandóan fel-alá ugrálva. Hogy van az, hogy a rendszer hosszú idő nélkül indul el fsckmikor indul végre a motor? És a válasz egyszerű. A beágyazott eszközök a gyökér fájlrendszerre támaszkodnak (rövidítve ro-rootfs (csak olvasható gyökér fájlrendszer)).
ro-rootfs számos olyan előnnyel jár, amelyek kevésbé nyilvánvalóak, mint a hitelesség. Egyik előnye, hogy a rosszindulatú programok nem tudnak rá írni /usr vagy /lib, ha egyetlen Linux folyamat sem tud oda írni. Egy másik, hogy a nagyrészt megváltoztathatatlan fájlrendszer kritikus fontosságú a távoli eszközök helyszíni támogatásához, mivel a támogató személyzet olyan helyi rendszerekre támaszkodik, amelyek névlegesen azonosak a helyszíni rendszerekkel. Talán a legfontosabb (de egyben a legalattomosabb) előny az, hogy a ro-rootfs arra kényszeríti a fejlesztőket, hogy eldöntsék, mely rendszerobjektumok lesznek megváltoztathatatlanok a rendszer tervezési szakaszában. A ro-rootf-ekkel való munka kínos és fájdalmas lehet, mivel a const változók gyakran vannak a programozási nyelvekben, de előnyeik könnyen indokolják a többletköltséget.
teremtés rootfs Az írásvédettség némi extra erőfeszítést igényel a beágyazott fejlesztők számára, és itt jön a képbe a VFS. A Linux megköveteli, hogy a fájlok benne legyenek /var írhatóak voltak, és emellett számos népszerű alkalmazás, amely beágyazott rendszereket futtat, megpróbálja létrehozni a konfigurációt dot-files в $HOME. A kezdőkönyvtárban lévő konfigurációs fájlok egyik megoldása általában az, hogy előgenerálják és beépítik őket rootfs. For /var Az egyik lehetséges megoldás egy külön írható partícióra való felcsatolás, míg / csak olvasható. Egy másik népszerű alternatíva a kötő- vagy fedőszerelvények használata.
Összekapcsolható és egymásra rakható tartók, használatuk konténerekben
Parancs végrehajtás man mount a legjobb módja a köthető és átfedhető csatolások megismerésének, amelyek lehetővé teszik a fejlesztők és a rendszergazdák számára, hogy fájlrendszert hozzanak létre az egyik útvonalon, majd tegyék ki azt egy másik alkalmazás számára. A beágyazott rendszerek esetében ez a fájlok tárolásának lehetőségét jelenti /var csak olvasható flash meghajtón, de egy átfedő vagy linkelhető csatolási útvonalon tmpfs в /var betöltéskor lehetővé teszi, hogy az alkalmazások oda jegyzeteket írjanak (scrawl). Amikor legközelebb bekapcsolja a módosításokat /var el fog veszni. Az átfedő rögzítés egyesülést hoz létre tmpfs és az alapul szolgáló fájlrendszert, és lehetővé teszi a meglévő fájlok látszólagos módosításait ro-tootf míg a kötözhető rögzítés az újakat üressé teheti tmpfs írható mappák ro-rootfs módokon. Míg overlayfs ez a megfelelő (proper) fájlrendszer típusa, bindable mount implementálva van .
Az overlay és a linkable mount leírása alapján ezen senki nem lepődik meg aktívan használják őket. Lássuk, mi történik, ha használjuk a tároló futtatásához az eszköz segítségével mountsnoop -tól bcc.
hívás system-nspawn elindítja a tárolót futás közben mountsnoop.py.
Nézzük meg mi történt:
dob mountsnoop míg a tároló "bootolás" alatt van, azt mutatja, hogy a tároló futásideje nagymértékben függ a csatolt csatolástól (csak a hosszú kimenet eleje látható).
Itt systemd-nspawn a kiválasztott fájlokat tartalmazza procfs и sysfs gazdagép a tárolóhoz, mint elérési út rootfs... kívül MS_BIND jelző, amely beállítja a kötési csatolást, néhány más jelző a csatoláson határozza meg a kapcsolatot a gazdagép és a tároló névtereinek változásai között. Például egy csatolt rögzítés kihagyhatja a módosításokat /proc и /sys a tárolóba, vagy elrejtheti őket a hívástól függően.
Következtetés
A Linux belső működésének megértése lehetetlen feladatnak tűnhet, hiszen maga a kernel hatalmas mennyiségű kódot tartalmaz, figyelmen kívül hagyva a Linux felhasználói terület alkalmazásokat és a C könyvtárak rendszerhívási felületeit, mint pl. glibc. Az előrelépés egyik módja az egyik kernel-alrendszer forráskódjának beolvasása, hangsúlyt fektetve a rendszerhívások és a felhasználói tér fejléceinek megértésére, valamint a fő belső kernel-interfészekre, például a táblázatra. file_operations. A fájlműveletek biztosítják a „minden fájl” elvet, így különösen élvezetes a kezelésük. C kernel forrásfájlok a legfelső szintű könyvtárban fs/ bemutatja a virtuális fájlrendszerek megvalósítását, amelyek egy burkolóréteg, amely széles körű és viszonylag egyszerű kompatibilitást biztosít a népszerű fájlrendszerek és tárolóeszközök között. A Linux névtereken keresztüli csatolás és átfedés beillesztése a VFS varázsa, amely lehetővé teszi a csak olvasható tárolók és gyökér fájlrendszerek létrehozását. A forráskód, az eBPF alapeszköz és felületének vizsgálatával kombinálva bcc
megkönnyítve a magfeltárást, mint valaha.
Barátaim, írjátok meg, hasznos volt számotokra ez a cikk? Esetleg van észrevétele, észrevétele? És akit érdekel a Linux Administrator tanfolyam, azt várjuk , amelyre április 18-án kerül sor.
Forrás: will.com