Kaixo guztioi, "Fitxategi-sistema birtualak" argitalpenaren bigarren zatia partekatzen dizuegu. LinuxZergatik dira beharrezkoak eta nola funtzionatzen dute? Lehenengo zatia irakur daiteke . Gogora dezagun argitalpen sorta hau ikastaroaren korronte berri baten abiaraztearekin bat egiteko garaia dela. , oso laster hasten dena.
Nola monitorizatu VFS eBPF eta bcc tresnak erabiliz
Nukleoak fitxategietan nola funtzionatzen duen ulertzeko modurik errazena sysfs praktikan ikustea da, eta ARM64 ikusteko modurik errazena eBPF erabiltzea da. eBPF (Berkeley Packet Filter laburdura) martxan dagoen makina birtual batek osatzen du , erabiltzaile pribilegiatuek eska dezaketen (query) komando-lerrotik. Nukleoaren iturriek kernelak zer egin dezakeen esaten diote irakurleari; eBPF tresnak kargatutako sistema batean exekutatzen nukleoa benetan zer egiten ari den erakusten du.

Zorionez, eBPF erabiltzen hastea nahiko erraza da tresnen laguntzarekin , banaketa orokorreko pakete gisa eskuragarri daudenak eta xehetasunez dokumentatua . Tresnak bcc C kodearen txertaketa txikiak dituzten Python script-ak dira, eta horrek esan nahi du bi hizkuntzak ezagutzen dituen edonork erraz alda ditzakeela. IN bcc/tools 80 Python script daude, hau da, ziurrenik garatzaile edo sistema administratzaile batek arazoa konpontzeko egokia den zerbait aukeratu ahal izango du.
VFSek exekutatzen ari den sistema batean egiten duten lanaren azaleko ideia bat izateko, saiatu vfscount edo vfsstat. Horrek erakutsiko du, demagun, dozenaka dei vfs_open() eta "bere lagunak" literalki segundoro gertatzen dira.

vfsstat.pyC kode txertaketak dituen Python script bat da, VFS funtzio-deiak besterik gabe zenbatzen dituena.
Eman dezagun adibide hutsal bat eta ikus dezagun zer gertatzen den USB pendrive bat ordenagailu batean sartzen dugunean eta sistemak detektatzen dugunean.

eBPF erabiliz zer gertatzen ari den ikus dezakezu
/sysUSB flash drive bat sartzen denean. Adibide sinple eta konplexu bat erakusten da hemen.
Goian erakusten den adibidean, bcc tresna komandoa exekutatzen denean mezu bat inprimatzen du sysfs_create_files(). Hori ikusten dugu sysfs_create_files() erabiliz abiarazi zen kworker stream-a flash drive txertatu zela erantzunez, baina zein fitxategi sortu zen? Bigarren adibideak eBPF-ren boterea erakusten du. Hemen trace.py Nukleoaren atzerako traza (-K aukera) eta sortu den fitxategiaren izena inprimatzen ditu sysfs_create_files(). Adierazpen bakarra txertatzea LLVM exekutatzen duen Python script-ak emandako formatu-kate erraz antzematen duen C kodea da. just-in-time konpilatzailea. Lerro hau konpilatu eta nukleoaren barruan dagoen makina birtualean exekutatzen du. Funtzio osoko sinadura sysfs_create_files () bigarren komandoan erreproduzitu behar da formatu-kateak parametroetako bati erreferentzia egin diezaion. C kode honetako akatsek C konpilagailuaren errore antzemangarriak eragiten dituzte. Adibidez, -l parametroa baztertzen bada, "Huts egin da BPF testua konpilatu" ikusiko duzu. C eta Python ezagutzen duten garatzaileek tresnak aurkituko dituzte bcc zabaltzeko eta aldatzeko erraza.
USB unitatea sartzen denean, nukleoaren atzerako trazatuak PID 7711 haria dela erakutsiko du kworkerfitxategia sortu zuena Β«eventsΒ» Π² sysfs. Horren arabera, deia sysfs_remove_files() diskoa kentzeak fitxategia ezabatzea eragin duela erakutsiko du events, erreferentziazko zenbaketaren kontzeptu orokorrari dagokiona. Aldi berean, ikustea sysfs_create_link () eBPF-rekin USB unitatea sartzen duzun bitartean gutxienez 48 lotura sinboliko sortu direla erakutsiko du.
Beraz, zertarako balio du gertaeren fitxategiak? Erabilera Bilaketarako , zer eragiten duen erakusten du disk_add_events (), eta bai "media_change"Edo "eject_request" gertaera fitxategi batean grabatu daiteke. Hemen nukleo-bloke geruzak erabiltzaile-esparruari "disko" bat agertu eta kanporatu dela jakinarazten dio. Kontuan izan ikerketa-metodo hau zenbaterainokoa den USB disko bat txertatuz, gauzak iturritik soilik nola funtzionatzen duten jakiteko saiakerarekin alderatuta.
Irakurtzeko soilik erro fitxategi-sistemek kapsulatutako gailuak gaitzen dituzte
Jakina, inork ez du zerbitzaria edo bere ordenagailua itzaltzen entxufea entxufetik aterata. Baina zergatik? Hau da, biltegiratze fisikoko gailuetan muntatutako fitxategi-sistemek idazketa atzeratuak izan ditzaketelako eta baliteke haien egoera erregistratzen duten datu-egiturak ez egotea biltegiratzeko idazketekin sinkronizatzea. Hori gertatzen denean, sistemaren jabeek hurrengo abiaraztera arte itxaron behar dute utilitatea abiarazteko. fsck filesystem-recovery eta, kasurik txarrenean, datuak galtzea.
Hala ere, denok dakigu IoT gailu asko, baita bideratzaileak, termostatoak eta autoak ere, orain funtzionatzen dutela LinuxGailu horietako askok ia ez dute erabiltzaile-interfazerik, eta ez dago modu garbirik itzaltzeko. Imajinatu bateria agortuta dagoen auto bat martxan jartzea kontrol-gailurako energia moztuta dagoenean. etengabe gora eta behera saltoka. Nola da sistema luze gabe abiarazten den fscknoiz hasten da azkenean motorra martxan? Eta erantzuna erraza da. Kapsulatutako gailuek erroko fitxategi-sisteman oinarritzen dira (laburtua ro-rootfs (irakurtzeko soilik erro fitxategi-sistema)).
ro-rootfs benetakotasuna baino agerikoak ez diren abantaila ugari eskaintzen ditu. Abantaila bat da malwareak ezin duela idatzi /usr edo /libprozesurik ez badago Linux ezin du bertan idatzi. Beste bat da fitxategi-sistema aldaezin bat ezinbestekoa dela urruneko gailuen lantokiko laguntzarako, laguntza-langileek tokiko sistemekin nominalki berdinak diren tokiko sistemak erabiltzen baitituzte. Abantaila garrantzitsuena (baina baita maltzurragoa ere) da ro-rootfs-ek garatzaileak sistemaren diseinuaren hasieran zein sistema-objektu izango diren aldaezinak erabakitzera behartzen dituela. Ro-rootfs-ekin lan egitea deserosoa eta mingarria izan daiteke, programazio-lengoaietako aldagai konstanteekin gertatzen den bezala, baina bere onurak gainditzen dituzte gastu gehigarriak.
sortzea rootfs Irakurtzeko soilik funtzionaltasunak ahalegin gehigarria eskatzen die txertatutako garatzaileei, eta hemen sartzen da jokoan VFS. Linux fitxategiak behar ditu /var idazteko modukoak ziren, eta gainera, sistema txertatuak exekutatzen dituzten aplikazio ezagun asko konfigurazioa sortzen saiatuko dira dot-files Π² $HOME. Hasierako direktorioko konfigurazio-fitxategietarako irtenbide bat horiek aurrez sortzea eta eraikitzea izan ohi da rootfs. For /var Ikuspegi posible bat partizio idazgarri bereizi batean muntatzea da, bitartean / irakurtzeko soilik muntatua. Beste alternatiba ezagun bat lotzeko edo gainjartzeko muntaketak erabiltzea da.
Lotura eta pilagarriak diren euskarriak, edukiontzien bidez erabiltzea
Agindu bat exekutatzen man mount lotu daitezkeen eta gainjar daitezkeen muntaketari buruz ikasteko modurik onena da, garatzaileei eta sistema-administratzaileei fitxategi-sistema bat bide batean sortzeko eta, ondoren, beste batean aplikazioetara erakusteko aukera ematen dietenak. Kapsulatutako sistemetarako, horrek fitxategiak gordetzeko gaitasuna esan nahi du /var irakurtzeko soilik den flash drive batean, baina gainjarri edo muntatzeko bide batetik tmpfs Π² /var kargatzean, aplikazioei oharrak bertan idazteko aukera emango die (marraztea). Aldaketak aktibatzen dituzun hurrengoan /var galduko da. Gainarrizko muntaketa batek arteko batasuna sortzen du tmpfs eta azpian dagoen fitxategi-sistema eta lehendik dauden fitxategietan itxurazko aldaketak egiteko aukera ematen dizu ro-tootf lotzeko moduko muntai batek, berriz, berriak huts egin ditzake tmpfs karpetak ikusgai daude idazteko moduan ro-rootfs moduak. Bitartean overlayfs hau da egokia (proper) fitxategi-sistema mota, muntaketa lotu daitekeen inplementatuta dago .
Gainjarri eta lotura-muntaiaren deskribapenean oinarrituta, inor ez da harritzen aktiboki erabiltzen dira. Ea zer gertatzen den erabiltzen dugunean tresna erabiliz edukiontzia martxan jartzeko mountsnoop tik bcc.
deiaren system-nspawn ontzia martxan jartzen duen bitartean mountsnoop.py.
Ikus dezagun zer gertatu den:
aireratzea mountsnoop edukiontzia "abiaraztean" dagoen bitartean, edukiontziaren exekuzio-denbora lotzen ari den muntatzearen menpekoa dela erakusten du (irteera luzearen hasiera bakarrik erakusten da).
Hemen systemd-nspawn aukeratutako fitxategiak eskaintzen ditu procfs ΠΈ sysfs ostalari ontzira bertarako bide gisa rootfs... Gainera MS_BIND lotura-muntaia konfiguratzen duen bandera, muntaian dauden beste bandera batzuek ostalariaren eta edukiontziaren izen-espazioen aldaketen arteko erlazioa definitzen dute. Adibidez, estekatutako muntaketa batek aldaketak salta ditzake /proc ΠΈ /sys edukiontzian sartu, edo ezkutatu deiaren arabera.
Ondorioa
Barne egitura ulertzea. Linux ezinezko zeregina dirudi, nukleoak berak kode kopuru handia baitu, erabiltzaile-espazioko aplikazioak alde batera utzita Linux eta sistema-deien interfazeak C liburutegietan, hala nola glibc. Aurrera egiteko modu bat nukleoaren azpisistema baten iturburu-kodea irakurtzea da, sistema-deiak eta erabiltzaile-espazioko goiburuak ulertzeari arreta jarriz, baita nukleoaren barneko interfaze nagusiak, adibidez, taula. file_operations. Fitxategien eragiketak "dena fitxategi bat da" printzipioa ematen du, eta kudeatzeko oso atseginak dira. C kernel iturburu-fitxategiak goi-mailako direktorioan fs/ fitxategi-sistema birtualen inplementazio bat adierazten dute, fitxategi-sistema ezagunen eta biltegiratze-gailuen arteko bateragarritasun zabala eta nahiko erraza eskaintzen duen bilgarri-geruza bat direnak. Izen-espazioen bidez lotuz eta gainjarriz muntatzea Linux β VFS-ren magia da edukiontziak eta irakurtzeko soilik diren erro fitxategi sistemak sortzea ahalbidetzen duena. Iturburu-kodearen azterketarekin, eBPF kernel tresnarekin eta bere interfazearekin konbinatuta bcc
muina esploratzea inoiz baino errazagoa eginez.
Lagunok, esadazue artikulu hau lagungarria izan den ala ez. Agian iruzkinik edo iradokizunik izango duzue? Eta "Administratzailea" ikastaroan interesa dutenentzat, Linux", gonbidatzen zaitugu , apirilaren 18an ospatuko dena.
Iturria: www.habr.com
