Përshëndetje të gjithëve, po ndajmë me ju pjesën e dytë të botimit "Sistemet virtuale të skedarëve në LinuxPse nevojiten dhe si funksionojnë? Pjesa e parë mund të lexohet . Le t'ju kujtojmë se kjo seri publikimesh është caktuar të përkojë me nisjen e një transmetimi të ri në kurs , e cila fillon shumë shpejt.
Si të monitoroni VFS duke përdorur veglat eBPF dhe bcc
Mënyra më e lehtë për të kuptuar se si funksionon kerneli në skedarë sysfs është ta shohësh atë në praktikë, dhe mënyra më e lehtë për të parë ARM64 është të përdorësh eBPF. eBPF (shkurt për Berkeley Packet Filter) përbëhet nga një makinë virtuale që funksionon , të cilën mund ta kërkojnë përdoruesit e privilegjuar (query) nga linja e komandës. Burimet e kernelit i tregojnë lexuesit se çfarë mund të bëjë kerneli; ekzekutimi i veglave eBPF në një sistem të ngarkuar tregon se çfarë po bën në të vërtetë kerneli.
Për fat të mirë, fillimi i përdorimit të eBPF është mjaft i lehtë me ndihmën e mjeteve , të cilat janë në dispozicion si paketa nga shpërndarja e përgjithshme dhe të dokumentuara në detaje . Mjetet bcc janë skriptet Python me futje të vogla të kodit C, që do të thotë se kushdo që njeh të dyja gjuhët mund t'i modifikojë lehtësisht. NË bcc/tools Ka 80 skripta Python, që do të thotë se ka shumë të ngjarë që një zhvillues ose administrator i sistemit do të jetë në gjendje të zgjedhë diçka të përshtatshme për zgjidhjen e problemit.
Për të marrë të paktën një ide sipërfaqësore të punës së VFS-ve në një sistem funksional, provoni vfscount ose vfsstat. Kjo do të tregojë, le të themi, se dhjetëra telefonata vfs_open() dhe "miqtë e tij" ndodhin fjalë për fjalë çdo sekondë.
vfsstat.pyështë një skript Python me futje të kodit C që thjesht numëron thirrjet e funksionit VFS.
Le të japim një shembull më të parëndësishëm dhe të shohim se çfarë ndodh kur futim një USB flash drive në një kompjuter dhe sistemi e zbulon atë.
Duke përdorur eBPF ju mund të shihni se çfarë po ndodh në
/syskur futet një USB flash drive. Një shembull i thjeshtë dhe kompleks është paraqitur këtu.
Në shembullin e treguar më sipër, bcc mjet printon një mesazh kur komanda është ekzekutuar sysfs_create_files(). Ne e shohim atë sysfs_create_files() u lançua duke përdorur kworker stream në përgjigje të faktit se flash drive ishte futur, por çfarë skedari u krijua? Shembulli i dytë tregon fuqinë e eBPF. Këtu trace.py Printon një prapavijë të kernelit (opsioni -K) dhe emrin e skedarit që është krijuar sysfs_create_files(). Futja e një deklarate të vetme është kod C që përfshin një varg formati lehtësisht të dallueshëm të ofruar nga skripti Python që ekzekuton LLVM përpilues vetëm në kohë. Ai e përpilon këtë linjë dhe e ekzekuton atë në një makinë virtuale brenda kernelit. Nënshkrimi i funksionit të plotë sysfs_create_files () duhet të riprodhohet në komandën e dytë në mënyrë që vargu i formatit t'i referohet njërit prej parametrave. Gabimet në këtë pjesë të kodit C rezultojnë në gabime të dallueshme nga përpiluesi C. Për shembull, nëse parametri -l hiqet, do të shihni "Dështoi përpilimi i tekstit BPF". Zhvilluesit që janë të njohur me C dhe Python do të gjejnë mjetet bcc lehtë për tu zgjeruar dhe ndryshuar.
Kur futet disku USB, gjurmimi i kernelit do të tregojë se PID 7711 është një thread kworkere cila krijoi skedarin «events» в sysfs. Prandaj, thirrja nga sysfs_remove_files() do të tregojë se heqja e diskut rezultoi në fshirjen e skedarit events, që korrespondon me konceptin e përgjithshëm të numërimit të referencës. Në të njëjtën kohë, duke parë sysfs_create_link () me eBPF gjatë futjes së USB-së do të tregojë se janë krijuar të paktën 48 lidhje simbolike.
Pra, çfarë kuptimi ka skedari i ngjarjeve? Përdorimi Për kërkim , tregon se çfarë shkakton disk_add_events (), dhe ose "media_change"Ose "eject_request" mund të regjistrohet në një skedar ngjarjeje. Këtu shtresa e bllokut të kernelit informon hapësirën e përdoruesit se një "disk" është shfaqur dhe nxjerrë jashtë. Vini re se sa informative është kjo metodë kërkimi duke futur një USB drive, në krahasim me përpjekjen për të kuptuar se si funksionojnë gjërat thjesht nga burimi.
Sistemet e skedarëve rrënjë vetëm për lexim mundësojnë pajisjet e integruara
Sigurisht, askush nuk e fik serverin ose kompjuterin e tij duke e tërhequr spinën nga priza. Por pse? Kjo për shkak se sistemet e skedarëve të montuar në pajisjet e ruajtjes fizike mund të kenë vonesa në shkrimet dhe strukturat e të dhënave që regjistrojnë gjendjen e tyre mund të mos sinkronizohen me shkrimet në ruajtje. Kur kjo ndodh, pronarët e sistemit duhet të presin deri në nisjen tjetër për të nisur programin. fsck filesystem-recovery dhe, në rastin më të keq, humbja e të dhënave.
Megjithatë, të gjithë e dimë se shumë pajisje IoT, si dhe routerë, termostate dhe makina, tani funksionojnë në LinuxShumë nga këto pajisje praktikisht nuk kanë ndërfaqe përdoruesi dhe nuk ka asnjë mënyrë për t'i fikur ato pa probleme. Imagjinoni të ndizni një makinë me një bateri të ngordhur kur ndërpritet energjia elektrike në pajisjen e kontrollit. duke kërcyer vazhdimisht lart e poshtë. Si ndodh që sistemi niset pa një kohë të gjatë fsckkur motori fillon të funksionojë më në fund? Dhe përgjigja është e thjeshtë. Pajisjet e integruara mbështeten në sistemin e skedarëve rrënjë (shkurtuar ro-rootfs (skedari rrënjë vetëm për lexim)).
ro-rootfs ofrojnë shumë përfitime që janë më pak të dukshme se vërtetësia. Një avantazh është se malware nuk mund të shkruajë në /usr ose /lib, nëse nuk ka proces Linux Nuk mund të shkruaj në të. Një tjetër është se një sistem skedarësh kryesisht i pandryshueshëm është thelbësor për mbështetjen në terren të pajisjeve në distancë, pasi personeli mbështetës përdor sisteme lokale që janë nominalisht identike me sistemet në vend. Ndoshta avantazhi më i rëndësishëm (por edhe më i fshehtë) është se ro-rootfs i detyron zhvilluesit të vendosin se cilat objekte të sistemit do të jenë të pandryshueshme në fillim të projektimit të sistemit. Puna me ro-rootfs mund të jetë e vështirë dhe e dhimbshme, siç ndodh shpesh me variablat const në gjuhët e programimit, por përfitimet e tij lehtësisht i tejkalojnë shpenzimet shtesë.
krijim rootfs Funksionaliteti vetëm për lexim kërkon disa përpjekje shtesë për zhvilluesit e integruar, dhe këtu hyn në lojë VFS. Linux kërkon që skedarët në /var ishin të shkruajtshme, dhe përveç kësaj, shumë aplikacione të njohura që ekzekutojnë sisteme të integruara do të përpiqen të krijojnë konfigurim dot-files в $HOME. Një zgjidhje për skedarët e konfigurimit në direktorinë e shtëpisë është zakonisht krijimi i para-gjenerimit dhe krijimit të tyre rootfs. Për /var Një qasje e mundshme është montimi i tij në një ndarje të veçantë të shkrueshme, ndërsa / montuar vetëm për lexim. Një alternativë tjetër popullore është përdorimi i montimeve me lidhje ose mbivendosje.
Montime të lidhura dhe të grumbullueshme, përdorimi i tyre nga kontejnerët
Ekzekutimi i komandës man mount është mënyra më e mirë për të mësuar rreth montimeve të lidhura dhe të mbivendosura, të cilat u japin zhvilluesve dhe administratorëve të sistemit mundësinë për të krijuar një sistem skedarësh në një rrugë dhe më pas për ta ekspozuar atë ndaj aplikacioneve në një tjetër. Për sistemet e integruara, kjo nënkupton aftësinë për të ruajtur skedarët në /var në një flash drive vetëm për lexim, por një shteg montimi mbivendosës ose i lidhur nga tmpfs в /var kur ngarkohet, do t'i lejojë aplikacionet të shkruajnë shënime atje (zhvarrosje). Herën tjetër që do të aktivizoni ndryshimet në /var do të humbasë. Një montim mbivendosje krijon një bashkim midis tmpfs dhe sistemin themelor të skedarëve dhe ju lejon të bëni ndryshime të dukshme në skedarët ekzistues në ro-tootf ndërsa një montim i lidhur mund t'i zbrazë të rejat tmpfs dosjet e dukshme si të shkruhet në ro-rootfs mënyrat. Derisa overlayfs kjo eshte e drejta (proper) lloji i sistemit të skedarëve, montimi i lidhshëm është implementuar në .
Bazuar në përshkrimin e montimit të mbivendosjes dhe të lidhjes, askush nuk është i befasuar për këtë ato përdoren në mënyrë aktive. Le të shohim se çfarë ndodh kur përdorim për të drejtuar kontejnerin duke përdorur mjetin mountsnoop nga bcc.
Вызов system-nspawn ndez kontejnerin gjatë funksionimit mountsnoop.py.
Le të shohim se çfarë ndodhi:
lëshim mountsnoop ndërsa kontejneri është "booting" tregon se koha e funksionimit të kontejnerit varet shumë nga montimi që lidhet (Shfaqet vetëm fillimi i daljes së gjatë).
Këtu systemd-nspawn ofron skedarë të zgjedhur në procfs и sysfs pritës në kontejner si shtigje drejt tij rootfs. përveç MS_BIND flamuri që konfiguron montimin lidhës, disa flamuj të tjerë në montim përcaktojnë marrëdhënien midis ndryshimeve në hapësirat e emrave të hostit dhe kontejnerit. Për shembull, një montim i lidhur mund të kapërcejë ndryshimet në /proc и /sys në kontejner ose fshehini ato në varësi të thirrjes.
Përfundim
Kuptimi i strukturës së brendshme Linux mund të duket si një detyrë e pamundur, pasi vetë bërthama përmban një sasi të madhe kodi, duke lënë mënjanë aplikacionet e hapësirës së përdoruesit Linux dhe ndërfaqet e thirrjeve të sistemit në libraritë C si p.sh. glibc. Një mënyrë për të bërë përparim është të lexoni kodin burimor të një nënsistemi kernel, me theks në kuptimin e thirrjeve të sistemit dhe titujve të hapësirës së përdoruesit, si dhe ndërfaqeve kryesore të brendshme të kernelit, të tilla si tabela file_operations. Operacionet e skedarëve ofrojnë parimin "çdo gjë është një skedar", duke i bërë ato veçanërisht të këndshme për t'u menaxhuar. Skedarët e burimit të kernelit C në drejtorinë e nivelit të lartë fs/ përfaqësojnë një implementim të sistemeve virtuale të skedarëve, të cilat janë një shtresë mbështjellëse që ofron përputhshmëri të gjerë dhe relativisht të thjeshtë midis sistemeve të njohura të skedarëve dhe pajisjeve të ruajtjes. Montimi me lidhje dhe mbivendosje përmes hapësirave të emrave Linux — është magjia e VFS që bën të mundur krijimin e kontejnerëve dhe sistemeve të skedarëve rrënjë vetëm për lexim. E kombinuar me një studim të kodit burimor, mjetit të kernelit eBPF dhe ndërfaqes së tij. bcc
duke e bërë eksplorimin bazë më të lehtë se kurrë.
Miq, më tregoni nëse ky artikull ju ka ndihmuar. Ndoshta keni ndonjë koment ose sugjerim? Dhe për ata që janë të interesuar në kursin "Administrator", Linux", ju ftojmë të , e cila do të zhvillohet më 18 prill.
Burimi: www.habr.com
