Përshëndetje të gjithëve, ne po ndajmë me ju pjesën e dytë të botimit "Sistemet e skedarëve virtualë në Linux: pse nevojiten dhe si funksionojnë?" Ju mund të lexoni pjesën e parë . 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.
Sidoqoftë, të gjithë e dimë se shumë pajisje IoT, si dhe ruterë, termostate dhe makina, tani përdorin Linux. Shumë nga këto pajisje kanë pak ose aspak ndërfaqe përdoruesi dhe nuk ka asnjë mënyrë për t'i fikur ato "në mënyrë të pastër". Imagjinoni të nisni një makinë me një bateri të ngordhur kur fuqia në njësinë e kontrollit është 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 asnjë proces Linux nuk mund të shkruajë atje. Një tjetër është se një sistem skedari kryesisht i pandryshueshëm është kritik për mbështetjen në terren të pajisjeve në distancë, pasi personeli mbështetës mbështetet në sisteme lokale që janë nominalisht identike me sistemet në terren. Ndoshta përfitimi 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ë fazën e projektimit të sistemit. Puna me ro-rootf mund të jetë e vështirë dhe e dhimbshme, pasi variablat konst shpesh janë në gjuhët e programimit, por përfitimet e tyre justifikojnë lehtësisht shpenzimet shtesë.
krijim rootfs Vetëm për lexim kërkon disa përpjekje shtesë për zhvilluesit e integruar, dhe këtu vjen në pah VFS. Linux kërkon që skedarët të jenë brenda /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
Të kuptuarit e funksionimit të brendshëm të Linux-it mund të duket si një detyrë e pamundur, pasi vetë kerneli përmban një sasi të madhe kodi, duke lënë mënjanë aplikacionet e hapësirës së përdoruesit të Linux-it dhe ndërfaqet e thirrjeve të sistemit në bibliotekat 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/ paraqesin një implementim të sistemeve të skedarëve virtualë, të cilët janë një shtresë mbështjellëse që siguron përputhshmëri të gjerë dhe relativisht të thjeshtë midis sistemeve të skedarëve të njohur dhe pajisjeve të ruajtjes. Lidhja dhe montimi i mbivendosjes nëpërmjet hapësirave të emrave Linux është magjia e VFS që bën të mundur krijimin e kontejnerëve vetëm për lexim dhe sistemeve të skedarëve rrënjë. Kombinuar me një ekzaminim të kodit burimor, mjetit bazë eBPF dhe ndërfaqes së tij bcc
duke e bërë eksplorimin bazë më të lehtë se kurrë.
Miq, shkruani, a ishte i dobishëm ky artikull për ju? Ndoshta keni ndonjë koment apo vërejtje? Dhe ata që janë të interesuar në kursin Linux Administrator janë të ftuar , e cila do të zhvillohet më 18 prill.
Burimi: www.habr.com