Ü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
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 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 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.py
egy 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
/sys
amikor 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 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 kworker
amely 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 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 fsck
mikor indul végre a motor? És a válasz egyszerű. A beágyazott eszközök a gyökér fájlrendszerre támaszkodnak 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 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
Forrás: will.com