Përshëndetje të gjithëve, po ndajmë me ju pjesën e dytë të publikimit "Sistemet virtuale të skedarëve në Linux: përse janë të nevojshme dhe si funksionojnë?" Pjesa e parë mund të lexoni . Le të kujtojmë, kjo seri publikimesh është e lidhur me lançimin e një fluksi të ri në kursin , i cili fillon shumë shpejt.
Si të vëzhgoni VFS me mjetet e eBPF dhe bcc
Mënyra më e thjeshtë për të kuptuar se si operon bërthama me skedarët sysfs është të shikoni këtë në praktikë, dhe mënyra më e thjeshtë për të parë ARM64 është të përdorni eBPF. eBPF (shkurtim për Berkeley Packet Filter) përbëhet nga një makinë virtuale që ekzekutohet në , të cilën përdoruesit me privilegje mund ta kërkojnë (query) nga linja e komandës. Burimet e bërthames i tregojnë lexuesit se çfarë mund të bëjë bërthama; ekzekutimi i mjeteve të eBPF në një sistem të ngarkuar tregon atë që bërthama në të vërtetë 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 distribuimi i përgjithshëm dhe janë dokumentuar në detaje . Mjetet bcc - janë skripte në Python me disa inserte të kodit në C, që do të thotë se çdo kush që njihet me të dyja gjuhët mund t'i modifikojë lehtësisht. Në bcc/tools ka 80 skripte Python, që do të thotë se gjasat janë që zhvilluesi ose administratori i sistemit mund të gjejë diçka të përshtatshme për të zgjidhur detyrën.
Për të marrë një ide fillestare rreth asaj që bëjnë VFS në një sistem të ngarkuar, provojeni vfscount или vfsstat. Kjo do të tregojë, për shembull, se dhjetëra thirrje vfs_open() dhe "miqtë e tij" ndodhin literalmente çdo sekondë.
vfsstat.py- është një skript në Python, me inserte të kodit në C, i cili thjesht numëron thirrjet e funksioneve të VFS.
Le të japim një shembull më të zakonshëm dhe të shohim se çfarë ndodh kur vendosim një USB flash drive në kompjuter dhe sistemi e zbulon.
Me ndihmën e eBPF, mund të shikoni se çfarë ndodh në
/syskur një USB flash drive është vendosur. Këtu tregohet një shembull i thjeshtë dhe një më kompleks.
Në shembullin e treguar lart, bcc një mjet shfaq një mesazh kur ekzekutohet komanda sysfs_create_files(). Ne shohim se sysfs_create_files() ka qenë e ekzekutuar me ndihmën e kworker një rrjedhe në përgjigje të asaj që ishte futur flash drive, por cili skedar u krijua gjatë kësaj? Shembulli i dytë tregon të gjithë fuqinë e eBPF. Këtu trace.py shfaq një gjurmë të trefishtë të bërthamës (kernel backtrace) (opsioni -K) dhe emrin e skedarit që u krijua sysfs_create_files(). Inkluzimi në shprehjet e vetme është një kod në C, i cili përfshin një varg formati të lehtë për t'u njohur, i ofruar nga një skript Python që ekzekuton LLVM kompilator just-in-time. Ky varg ai e përpunon dhe e ekzekuton në një makinë virtuale brenda bërthamës. Nënshkrimi i plotë i funksionit sysfs_create_files () duhet të riprodhohet në komandën tjetër, në mënyrë që vargu i formatit të mund të referohet në një nga parametrat. Gabimet në këtë fragment të kodit në C shkaktojnë gabime të njohura të kompilatorit C. Për shembull, nëse një parametër -l është i munguar, do të shihni "Failed to compile BPF text." Zhvilluesit që janë të njohur mirë me C dhe Python, do të gjejnë mjetet bcc të lehta për t'u zgjeruar dhe ndryshuar.
Kur pendësi USB është i futur, gjurma e bërthamës do të tregojë se PID 7711 është një proces kworker, i cili krijoi skedarin "events" në sysfs. Në përputhje me këtë, thirrja me sysfs_remove_files() do të tregojë se heqja e pendës ka çuar në heqjen e skedarit events, e cila është në përputhje me konceptin e përgjithshëm të numërimit të referencave. Megjithatë, shikimi sysfs_create_link () me eBPF gjatë futjes së pendës USB do të tregojë se janë krijuar të paktën 48 lidhje simbolike.
Cili është kuptimi i skedarit events? Përdorimi i për të kërkuar , tregon se ajo thërret disk_add_events (), dhe ose "media_change", ose "eject_request" mund të shkruhen në skedarin e ngjarjeve. Këtu, shtresa bllokuese e bërthamës e informon userspace për shfaqjen dhe heqjen e "diskut". Vini re se sa informativ është ky metod i hulumtimit në shembullin e futjes së pendës USB në krahasim me përpjekjet për të kuptuar se si funksionon gjithçka, ekskluzivisht nga burimet.
Sistemet e skedarëve vetëm për lexim bëjnë të mundur pajisjet e ndërtuara
Sigurisht, askush nuk e fik serverin apo kompjuterin e tij duke tërhequr kabllin nga prizë. Por pse? Sepse sistemet e skedarëve të montuara në pajisjet fizike të ruajtjes mund të kenë shkrime të vonuara, dhe strukturat e të dhënave që regjistrojnë gjendjen e tyre mund të mos sinkronizohen me regjistrimet në ruajtje. Kur ndodh kjo, pronarët e sistemit duhet të presin ngarkimin e ardhshëm për të ekzekutuar utilitarin fsck filesystem-recovery dhe, në rastin më të keq, të humbasin të dhënat.
Megjithatë, të gjithë ne e dimë se shumë pajisje IoT, si dhe ruterët, termostatët dhe automobilat tani funksionojnë nën Linux. Shumica e këtyre pajisjeve kanë pothuajse asnjë ndërfaqe përdoruesi, dhe nuk ka asnjë mënyrë për t'i fikur ato 'në mënyrë të pastër'. Imagjinoni të nisi një automobil me bateri të shkarkuar, kur alimentimi i pajisjes kontrolluese ka një alternim të vazhdueshëm lart-poshtë. Si është e mundur që sistemi ngarkohet pa një fsck, kur motori përfundimisht fillon? Dhe përgjigjja është e thjeshtë. Pajisjet e integruara mbështeten në sistemin e skedarëve rrënjësor (e shkurtuar ro-rootfs (sistemi i skedarëve rrënjësor të lexueshëm vetëm).
ro-rootfs ofrojnë shumë përfitime, të cilat janë më pak të dukshme se autenticiteti. Një nga përfitimet është se malware nuk mund të shkruajë në /usr или /lib, nëse asnjë proces Linux nuk mund të shkruajë aty. Një tjetër është se një sistem i skedarëve kryesisht të pandryshueshëm është thelbësor për mbështetje në terren për pajisjet e largëta, pasi stafi ndihmës përdor sisteme lokale, të cilat nominalisht janë identike me sistemet në terren. Ndoshta përfitimi më i rëndësishëm (por edhe më i trazuar) është se ro-rootfs detyron zhvilluesit të vendosin se cilat objekte sistemike do të mbeten të pandryshueshme, akoma në fazën e projektimit të sistemit. Të punosh me ro-rootfs mund të jetë e pakëndshme dhe e dhimbshme, siç ndodh shpesh me variablat const në gjuhët e programimit, por përfitimet e tyre lehtësisht justifikojnë koston e shtuara.
Krijimi rootfs të lexueshëm vetëm kërkon disa përpjekje shtesë për zhvilluesit e sistemeve të integruara, dhe këtu hyn në skenë VFS. Linux kërkon që skedarët në /var të jenë të qasshëm për shkruajtur, dhe, për më tepër, shumë aplikacione popullore që drejtojnë sistemet e integruara, do të përpiqen të krijojnë skedarë konfigurimi dot-files në $HOME. Një nga zgjidhjet për skedarët e konfigurimit në katalogun e shtëpisë zakonisht është krijimi i tyre paraprak dhe grumbullimi në rootfs. Për /var një nga qasjet e mundshme është ta ngresh në një pjesë të veçantë, të qasshme për shkruajtur, ndërsa vetë / ngrihet vetëm për lexim.
Mounts që lidhen dhe i zhvendosen, përdorimi i tyre nga kontejnerët
Ekzekutimi i komandës man mount – mënyra më e mirë për të mësuar rreth mount-ve të lidhura dhe të zhvendosura, të cilat u japin zhvilluesve dhe administratorëve të sistemit mundësinë të krijojnë një sistem skedarash në një rrugë, dhe më pas ta ofrojnë atë aplikacioneve në një tjetër. Për sistemet e integruara, kjo do të thotë mundësia për të ruajtur skedarë në /var në një pajisje flash që është e aksesueshme vetëm për lexim, por montimi i zhvendosur ose i lidhur i një rruge nga tmpfs në /var në ngarkesë do të lejojë aplikacionet të shkruajnë notat atje (scrawl). Në ndezjen e ardhshme, ndryshimet në /var do të humbasin. Montimi i zhvendosur krijon një bashkëngjitje midis tmpfs dhe sistemit skedar poshtë dhe lejon ndryshimet e dukshme të skedarëve ekzistues në ro-tootf ndërsa montimi i lidhur mund të bëjë që dosjet e reja të zbrazëta të tmpfs të duken si të aksesueshme për shkrim në ro-rootfs rruga. Ndërkohë që overlayfs është lloji i duhur (proper) i sistemit skedar, montimi i lidhur është realizuar në .
Duke u bazuar në përshkrimin e montimit të zhvendosur dhe të lidhur, askush nuk është i befasuar se i përdorin ato aktivisht. Le të shikojmë se çfarë ndodh kur ne përdorim për të nisur një kontejner, duke përdorur mjetin mountsnoop от bcc.
Thirrja system-nspawn e nis kontejnerin gjatë punës mountsnoop.py.
Le të shohim se çfarë ndodhi:
Nisja mountsnoop gjatë "ngarkesës" së kontejnerit tregon se mjedisi i ekzekutimit të kontejnerit varet fort nga montimi i lidhur (Shfaqet vetëm fillimi i një dalje të gjatë).
Këtu systemd-nspawn siguron skedarët e zgjedhur në procfs и sysfs të host-it në kontejner si rrugë në të rootfs. Përveç MS_BIND flamurit që vendos montimin e lidhur, disa flamuj të tjerë në sistemin e montimit përcaktojnë marrëdhënien midis ndryshimeve në hapësirën e emrave të host-it dhe kontejnerit. Për shembull, montimi i lidhur mund të lejojë ose të fshehë ndryshimet në /proc и /sys në kontejner, në varësi të thirrjes.
Përfundim
Të kuptosh strukturën e brendshme të Linux mund të duket një detyrë e pamundur, sepse vetë bërthama përmban një sasi të madhe kodi, duke lënë mënjanë aplikacionet e hapësirës përdoruese të Linux dhe ndërfaqet e thirrjeve sistemike në bibliotekat në gjuhën C, siç janë glibc. Një nga mënyrat për të arritur përparim është të lexosh kodin burimor të një nënsistemi të bërthamës me fokus në kuptimin e thirrjeve sistemike dhe titujve që i drejtohen hapësirës së përdoruesit, si dhe ndërfaqeve kryesore të brendshme të bërthamës, për shembull, tabela file_operations. Operacionet e skedarëve ofrojnë parimin "çdo gjë është një skedare", prandaj 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 të lartë fs/ paraqesin implementimin e sistemeve të skedarëve virtualë, që janë një shtresë mbulese që ofron një kompatibilitet të gjerë dhe relativisht të thjeshtë me sistemet e skedarëve dhe pajisjet e ruajtjes. Montimi me lidhje dhe mbivendosje nëpërmjet emrave të hapësirave Linux është magjia VFS, e cila e bën të mundur krijimin e kontejnerëve dhe sistemeve të skedarëve me lexim vetëm. Në kombinim me studimin e kodit burimor, mjeti i bërthamës eBPF dhe ndërfaqja e tij bcc
e bëjnë hulumtimin e bërthamës më të lehtë se kurrë.
Miq, na shkruani nëse ky artikull ishte i dobishëm për ju? Ndoshta keni ndonjë koment apo vërejtje? Dhe ata që janë të interesuar për kursin "Administrator Linux", i ftojmë në , e cila do të zhvillohet më 18 prill.
Burimi: habr.com
