Përshëndetje të gjithëve, po ndajmë me ju pjesën e dytë të publikimit "Sistemet virtuale të skedarëve në Linux: për çfarë janë të nevojshme dhe si funksionojnë?" Pjesën e parë mund ta lexoni . Kujtojmë, kjo seri publikimesh është lidhur me lancimin e një fluksi të ri të kursit , i cili do të fillojë shumë shpejt.
Si të vëzhgoni VFS me mjetet e eBPF dhe bcc
Mënyra më e thjeshtë për të kuptuar si operon bërthama me skedarët sysfs është të shikoni këtë në praktikë, dhe mënyra më e lehtë për të vëzhguar ARM64 është të përdorni eBPF. eBPF (shkurtim për Berkeley Packet Filter) përbëhet nga një makinë virtuale që funksionon në , të cilën përdoruesit me privilegje mund ta kërkojnë (query) nga komanda e rreshtit. Burimet e bërthamos tregojnë lexuesit se çfarë mund të bëjë bërthama; ekzekutimi i mjeteve eBPF në një sistem të ngarkuar tregon se çfarë bërthama realisht bën.
Fatmirësisht, fillimi i përdorimit të eBPF është mjaft i lehtë me ndihmën e mjeteve , të cilat janë të disponueshme si paketa nga shpërndarja e zakonshme dhe janë dokumentuar në detaje Mjetet bcc – janë skripte në Python me disa pjesë kodi në C, që do të thotë se çdo kush që njeh të dyja gjuhët mund t'i modifikojë lehtësisht ato. Në bcc/tools ka 80 skripte Python, dhe kjo do të thotë se ka shumë mundësi që një zhvillues ose administrator sistemi të jetë në gjendje të gjejë diçka të përshtatshme për të zgjidhur detyrën.
Për të marrë një përmbledhje të paktën të sipërfaqshme të asaj që bëjnë VFS në sistemin e nisur, provoni vfscount ose vfsstat. Kjo do të tregojë, për shembull, se dhjetëra thirrje vfs_open() dhe "miqtë e tij" ndodhin praktikisht çdo sekondë.
vfsstat.pyështë një skript në Python, me disa pjesë kodi në C, që thjesht numëron thirrjet e funksioneve VFS.
Le të japim një shembull më trivial dhe të shohim se çfarë ndodh kur ne lidhemi një USB dhe sistemi e zbulon atë.
Me ndihmën e eBPF, mund të shohim se çfarë ndodh në
/sys, kur lidhet një USB. Këtu është një shembull i thjeshtë dhe një tjetër më kompleks.
Në shembullin e treguar më lart, bcc mjetin jep një mesazh kur ekzekutohet komanda sysfs_create_files(). Ne shohim se sysfs_create_files() u ekzekutua nga kworker rrjedhës në përgjigje të asaj që USB u fut, por cili skedar u krijua? Shembulli i dytë tregon të gjitha fuqitë e eBPF. Këtu trace.py tregon një gjurmë të përmbysur të bërthamës (kernel backtrace) (opsioni -K) dhe emrin e skedarit që u krijua. sysfs_create_files()Futja në thënie të vetme është kodi në C, që përfshin një varg formati të lehtë për t'u njohur, i cila sigurohet nga një skript Python që ekzekuton LLVM. kompilues just-in-time.Ky varg ai e kompilon dhe ekzekuton në një makinë virtuale brenda bërthamës. Nënshkrimi i plotë i funksionit sysfs_create_files () duhet të riprodhohet në komandën e dytë, që të mund të referohet në një nga parametrat. Gabimet në këtë fragment kodi në C dërgojnë në gabime të njohura të kompilatorit C. Për shembull, nëse parametri -l është i harruar, do të shihni "Dështoi për të kompiluar tekstin BPF." Zhvilluesit që njohin mirë C dhe Python do t'i gjejnë mjetet bcc të thjeshta për t'u zgjeruar dhe ndryshuar.
Kur USB-in futet, gjurma e përmbysur e bërthamës do të tregojë se PID 7711 është rrjedha kworker, që krijoi skedarin "events" në sysfs. Përkatësisht, thirrja me sysfs_remove_files() do të tregojë se heqja e njësisë ka çuar në heqjen e skedarit events., që përputhet me konceptin e përgjithshëm të numërimit të lidhjeve. Në të njëjtën kohë, shikimi sysfs_create_link () me eBPF gjatë përfshirjes së një disku USB do të tregojë se janë krijuar të paktën 48 lidhje simbolike.
Pra, çfarë kuptimi ka skedari events? Përdorimi për kërkimin , tregon se ajo thërret disk_add_events (), dhe ose "media_change", ose "eject_request" mund të regjistrohen në skedarin e ngjarjeve. Këtu, shtresa bllokuese e bërthamës informon userspace për shfaqjen dhe nxjerrjen e "diskut". Vini re se sa informuese është ky metodë eksplorimi në shembullin e përfshirjes së një disku USB krahas përpjekjeve për të kuptuar se si funksionon gjithçka ekskluzivisht nga burimet e kodit.
Sistemet e skedarëve root vetëm për lexim bëjnë të mundshme pajisjet e integruara.
Sigurisht, askush nuk e ndalon serverin ose kompjuterin e tij duke e tërhequr prizën nga shtëpia. Por pse? Sepse sistemi i instaluar i skedarëve në pajisjet fizike të ruajtjes mund të ketë shënime të shtyra dhe strukturat e të dhënave që regjistrojnë gjendjen e tyre mund të mos sinkronizohen me shënimet në ruajtje. Kur ndodh kjo, pronarët e sistemit duhet të presin ngarkimin e ardhshëm për të aktivizuar utilitarin. fsck filesystem-recovery dhe, në rastin më të keq, për të humbur të dhënat.
Megjithatë, të gjithë ne e dimë se shumë pajisje IoT, si dhe routerat, termostatet dhe automjetet tani punojnë me Linux. Shumica e këtyre pajisjeve praktikisht nuk kanë ndërfaqe përdoruesi dhe nuk ka asnjë mënyrë për t'i ndalur ato "pastër". Paraqitni një makinë me një bateri të shkarkuar, kur energjia e pajisjes kontrolluese është përherë duke u lëkundur lart-poshtë. Si ndodh që sistemi ngarkohet pa një periudhë të gjatë fsck, kur motori përfundimisht fillon të punojë? Dhe përgjigja është e thjeshtë. Pajisjet e integruara mbështeten në sistemin e skedarëve rrënjësor (për shkurtim ro-rootfs (sistemi i skedarëve rrënjësor të lexueshëm).
ro-rootfs ofrojnë shumë përfitime që janë më pak të dukshme se sa autenticiteti. Një nga përfitimet është se malware nuk mund të shkruaj në /usr ose /lib, nëse asnjë proces Linux nuk mund të shkruaj atje. Një tjetër është se një sistem dosjesh kryesisht të pandryshueshëm është thelbësor për mbështetje në terren të pajisjeve të largëta, pasi stafi ndihmës përdor sisteme lokale që janë emra nominal të barabartë me sistemet në vend. Ndoshta, përfitimi më i rëndësishëm (por edhe më i pashmangshëm) është se ro-rootfs i detyron zhvilluesit të vendosin se cilat objekte sistemike do të jenë të pandryshueshme që në fazën e projektimit të sistemit. Punimi me ro-rootfs mund të jetë i pakëndshëm dhe i dhimbshëm, siç ndodh shpesh me variablat const në gjuhët e programimit, por përfitimet e tyre e kompensojnë lehtësisht kostot shtesë.
Krijimi rootfs leximi i vetëm kërkon disa përpjekje të tjera nga zhvilluesit e sistemeve të integruara, dhe pikërisht këtu hyn në skenë VFS. Linux kërkon që skedarët në /var ishinë të disponueshme për shkruar, dhe, për më tepër, shumë aplikacione të njohura që drejtojnë sistemet e integruara do të përpiqen të krijojnë konfigurime dot-files në $HOME. Një nga zgjidhjet për skedarët e konfigurimit në katalogun e shtëpisë zakonisht është gjenerimi i tyre paraprak dhe ndërtimi në rootfs. Për /var një nga qasjet e mundshme është ta montoni atë në një seksion të veçantë, të disponueshëm për shkruar, ndërsa vetë / monitohet vetëm për lexim. Një alternativë e njohur tjetër është përdorimi i montimeve të lidhura ose mbulues (bind or overlay mounts).
Montimet e lidhura dhe mbulues, përdorimi i tyre nga kontejnerët
Ekzekutimi i komandës man mount është mënyra më e mirë për të mësuar për montimet e lidhura dhe mbulues, të cilat u japin zhvilluesve dhe administratorëve të sistemeve mundësinë për të krijuar një sistem skedari në një rrugë, dhe pastaj ta ofrojnë atë aplikacioneve në një tjetër. Për sistemet e integruara, kjo do të thotë mundësinë për të ruajtur skedarët në /var në një memorie flash, e cila është vetëm për lexim, por montimi i mbuluar ose i lidhur i një rruge nga tmpfs në /var në ngarkim do të lejojë aplikacionet të shkruajnë shënime atje (scrawl). Në përfshirjen e ardhshme ndryshimet në /var do të humbasin. Montimi i mbivendosur krijon një lidhje mes tmpfs dhe sistemit të skedarëve nëntokësor dhe lejon të bëhen dukshëm ndryshime në skedarët ekzistues në ro-tootf ndërsa montimi lidhës mund të bëjë dosje të reja të zbrazëta tmpfs të dukshme si të disponueshme për shkrim në ro-rootfs rrugët. Ndërsa overlayfs është tipi i duhur (proper) i sistemit të skedarëve, montimi lidhës është zbatuar në .
Duke u bazuar në përshkrimin e montimit të mbivendosur dhe atij lidhës, askush nuk habitet që i përdorin aktivisht ato. Le të shohim se çfarë ndodh kur përdorim për të nisur një konteiner, duke përdorur mjetin mountsnoop nga bcc.
Thirrja system-nspawn nis një konteiner gjatë operimit mountsnoop.py.
Le të shohim se çfarë dolën;
Fillimi mountsnoop gjatë "ngarkimit" të konteinerit, tregon se mjedisi i ekzekutimit të konteinerit është dukshëm i varur nga montimi lidhës (Tregohet vetëm fillimi i daljes së gjatë).
Këtu systemd-nspawn siguron skedarët e përzgjedhur në procfs dhe sysfs të host-it në konteiner si rrugë në rootfs. Përveç MS_BIND flamës, e cila vendos montimin e lidhjes, disa flamuj të tjerë në sistemin e montimit përcaktojnë marrëdhënien midis ndryshimeve në hapësirën emërore të hostit dhe kontejnerit. Për shembull, montimi i lidhjes mund të kalojë ndryshimet në /proc dhe /sys kontejner, ose t'i fsheh ato në varësi të thirrjes.
Përfundimi
Kuptimi i brendshëm të Linux-it mund të duket si një detyrë e pamundur, pasi vetë bërthama përmban një sasi të madhe kodi, duke lënë përjashtim aplikacionet e hapësirës përdoruese të Linux-it dhe ndërfaqet e thirrjeve sistemore në bibliotekat në gjuhën C, si glibc. Një nga mënyrat për të përparuar është të lexoni kodin burimor të një nën sistemi të bërthamës me fokus në kuptimin e thirrjeve sistemore dhe titujve të drejtuar në hapësirën e përdoruesit, si dhe ndërfaqet kryesore të brendshme të bërthamës, për shembull, tabela file_operations. Operacionet e skedarëve sigurojnë parimin "gjithçka është skedar", kështu që menaxhimi i tyre është veçanërisht i këndshëm. Skedarët burimorë të bërthamës në gjuhën C ndodhen në katalogun e nivelit më të lartë fs/ përfaqësojnë implementimin e sistemeve virtuale të skedarëve, të cilat janë një shtresë mbulesë që ofron një kompatibilitet të gjerë dhe relativisht të thjeshtë me sistemet e njohura të skedarëve dhe pajisjet e ruajtjes. Montimi me lidhje dhe mbivendosje përmes hapësirave emrash në Linux është magjia e VFS, e cila bën të mundur krijimin e kontejnerëve dhe sistemeve të skedarëve të leximit vetëm. Në kombinim me studimin e kodit burimor, mjeti i bërthamës eBPF dhe ndërfaqja e tij bcc
e bëjnë studimin e bërthamës më të thjeshtë se kurrë.
Shokë, na shkruani nëse ky artikull ishte i dobishëm për ju? Ndoshta keni ndonjë koment apo vërejtje? Për ata që janë të interesuar në kursin "Administratori Linux", ju ftojmë në , i cili do të zhvillohet më 18 prill.
Burimi: habr.com
