Kumusta sa lahat, ibinabahagi namin sa iyo ang ikalawang bahagi ng publikasyong “Virtual file system sa Linux: bakit kailangan ang mga ito at paano ito gumagana?” Maaari mong basahin ang unang bahagi . Paalalahanan ka namin na ang serye ng mga publikasyong ito ay nakatakdang magkasabay sa paglulunsad ng bagong stream sa kurso , na magsisimula sa lalong madaling panahon.
Paano subaybayan ang VFS gamit ang mga tool ng eBPF at bcc
Ang pinakamadaling paraan upang maunawaan kung paano gumagana ang kernel sa mga file sysfs ay upang makita ito sa pagsasanay, at ang pinakamadaling paraan upang panoorin ang ARM64 ay ang paggamit ng eBPF. Ang eBPF (maikli para sa Berkeley Packet Filter) ay binubuo ng isang virtual machine na tumatakbo , na maaaring hilingin ng mga may pribilehiyong user (query) mula sa command line. Ang mga mapagkukunan ng kernel ay nagsasabi sa mambabasa kung ano ang magagawa ng kernel; ang pagpapatakbo ng mga tool ng eBPF sa isang load system ay nagpapakita kung ano ang aktwal na ginagawa ng kernel.
Sa kabutihang palad, ang pagsisimula sa paggamit ng eBPF ay medyo madali sa tulong ng mga tool , na magagamit bilang mga pakete mula sa pangkalahatang pamamahagi at nakadokumento nang detalyado . Mga gamit bcc ay mga script ng Python na may maliit na pagsingit ng C code, na nangangahulugan na ang sinumang pamilyar sa parehong mga wika ay madaling baguhin ang mga ito. SA bcc/tools Mayroong 80 script ng Python, na nangangahulugang malamang na ang isang developer o system administrator ay makakapili ng isang bagay na angkop para sa paglutas ng problema.
Upang makakuha ng hindi bababa sa isang mababaw na ideya kung ano ang ginagawa ng mga VFS sa isang tumatakbong sistema, subukan vfscount o vfsstat. Ipapakita nito, sabihin natin, na dose-dosenang mga tawag vfs_open() at literal na nangyayari ang "kanyang mga kaibigan" bawat segundo.
vfsstat.pyay isang script ng Python na may mga pagsingit ng C code na binibilang lamang ang mga tawag sa function ng VFS.
Magbigay tayo ng mas maliit na halimbawa at tingnan kung ano ang mangyayari kapag nagpasok tayo ng USB flash drive sa isang computer at nakita ito ng system.
Gamit ang eBPF makikita mo kung ano ang nangyayari sa
/syskapag may nakapasok na USB flash drive. Ang isang simple at kumplikadong halimbawa ay ipinapakita dito.
Sa halimbawang ipinakita sa itaas, bcc kasangkapan nagpi-print ng mensahe kapag pinapatakbo ang command sysfs_create_files(). Nakikita natin yan sysfs_create_files() ay inilunsad gamit ang kworker stream bilang tugon sa katotohanan na ang flash drive ay ipinasok, ngunit anong file ang nilikha? Ang pangalawang halimbawa ay nagpapakita ng kapangyarihan ng eBPF. Dito trace.py Nagpi-print ng kernel backtrace (-K na opsyon) at ang pangalan ng file na ginawa sysfs_create_files(). Ang single statement insertion ay C code na may kasamang string ng format na madaling makilala na ibinigay ng Python script na nagpapatakbo ng LLVM just-in-time compiler. Pinagsasama-sama nito ang linyang ito at isinasagawa ito sa isang virtual machine sa loob ng kernel. Full function na lagda sysfs_create_files () ay dapat na kopyahin sa pangalawang utos upang ang format na string ay maaaring sumangguni sa isa sa mga parameter. Ang mga error sa piraso ng C code na ito ay nagreresulta sa mga nakikilalang error mula sa C compiler. Halimbawa, kung inalis ang -l parameter, makikita mo ang "Nabigong i-compile ang BPF text." Ang mga developer na pamilyar sa C at Python ay makakahanap ng mga tool bcc madaling palawakin at baguhin.
Kapag ang USB drive ay ipinasok, ang kernel backtrace ay magpapakita na ang PID 7711 ay isang thread kworkerna lumikha ng file «events» в sysfs. Alinsunod dito, ang tawag mula sa sysfs_remove_files() ay magpapakita na ang pag-alis ng drive ay nagresulta sa pagtanggal ng file events, na tumutugma sa pangkalahatang konsepto ng pagbibilang ng sanggunian. Kasabay nito ang pagtingin sysfs_create_link () na may eBPF habang ipinapasok ang USB drive ay magpapakita na hindi bababa sa 48 simbolikong link ang nagawa.
Kaya ano ang punto ng file ng mga kaganapan? Paggamit Para sa paghahanap , ay nagpapakita kung ano ang sanhi nito disk_add_events (), at alinman "media_change"O "eject_request" maaaring maitala sa isang file ng kaganapan. Dito ipinapaalam ng kernel block layer ang userspace na may lumabas na "disk" at na-eject. Pansinin kung gaano kabatid ang paraan ng pananaliksik na ito sa pamamagitan ng paglalagay ng USB drive, kumpara sa pagsubok na alamin kung paano gumagana ang mga bagay mula sa pinagmulan.
Ang mga read-only na root file system ay nagpapagana ng mga naka-embed na device
Siyempre, walang isasara ang server o ang kanilang computer sa pamamagitan ng paghila ng plug mula sa socket. Pero bakit? Ito ay dahil ang mga naka-mount na file system sa mga pisikal na storage device ay maaaring may mga lagging write, at ang mga istruktura ng data na nagtatala ng kanilang estado ay maaaring hindi naka-synchronize sa mga writes sa storage. Kapag nangyari ito, ang mga may-ari ng system ay kailangang maghintay hanggang sa susunod na boot upang ilunsad ang utility. fsck filesystem-recovery at, sa pinakamasamang kaso, pagkawala ng data.
Gayunpaman, alam nating lahat na maraming IoT device, pati na rin ang mga router, thermostat at kotse, ay nagpapatakbo na ngayon ng Linux. Marami sa mga device na ito ay may kaunti o walang user interface, at walang paraan upang i-off ang mga ito nang "malinis." Isipin na simulan ang isang kotse na may patay na baterya kapag ang kapangyarihan sa control unit ay patuloy na tumatalon pataas at pababa. Paano ito na ang sistema ay nagbo-boot nang walang haba fsckkailan sa wakas magsisimula ang makina? At ang sagot ay simple. Ang mga naka-embed na device ay umaasa sa root file system (dinaglat ro-rootfs (read-only root filesystem)).
ro-rootfs nag-aalok ng maraming benepisyo na hindi gaanong halata kaysa sa pagiging tunay. Ang isang bentahe ay hindi maaaring sumulat ang malware /usr o /lib, kung walang proseso ng Linux ang makakasulat doon. Ang isa pa ay ang isang malaking hindi nababagong file system ay kritikal para sa field na suporta ng mga malalayong device, dahil ang mga tauhan ng suporta ay umaasa sa mga lokal na system na halos kapareho ng mga field system. Marahil ang pinakamahalaga (ngunit pinaka-mapanirang) benepisyo ay pinipilit ng ro-rootfs ang mga developer na magpasya kung aling mga object ng system ang hindi nababago sa yugto ng disenyo ng system. Ang pagtatrabaho sa mga ro-rootfs ay maaaring maging awkward at masakit, dahil ang mga variable ng const ay kadalasang nasa mga programming language, ngunit ang kanilang mga benepisyo ay madaling nagbibigay-katwiran sa karagdagang overhead.
paglikha rootfs Ang read-only ay nangangailangan ng ilang dagdag na pagsusumikap para sa mga naka-embed na developer, at dito makikita ang VFS. Kinakailangan ng Linux na ang mga file ay nasa /var ay maaaring isulat, at bilang karagdagan, maraming sikat na application na nagpapatakbo ng mga naka-embed na system ang susubukang gumawa ng configuration dot-files в $HOME. Ang isang solusyon para sa mga file ng pagsasaayos sa direktoryo ng bahay ay karaniwang paunang pagbuo at pagbuo ng mga ito rootfs. Para sa /var Ang isang posibleng diskarte ay i-mount ito sa isang hiwalay na nasusulat na partisyon, habang / naka-mount na read-only. Ang isa pang tanyag na alternatibo ay ang paggamit ng bind o overlay mounts.
Nai-link at nasasalansan na mga mount, ang kanilang paggamit ng mga lalagyan
Pagpapatupad ng utos man mount ay ang pinakamahusay na paraan upang matutunan ang tungkol sa mga bindable at overlayable na mga mount, na nagbibigay sa mga developer at system administrator ng kakayahang gumawa ng file system sa isang path at pagkatapos ay ilantad ito sa mga application sa isa pa. Para sa mga naka-embed na system, nangangahulugan ito ng kakayahang mag-imbak ng mga file /var sa isang read-only na flash drive, ngunit isang overlay o linkable mount path mula sa tmpfs в /var kapag naglo-load, papayagan nito ang mga application na magsulat ng mga tala doon (scrawl). Sa susunod na i-on mo ang mga pagbabago sa /var Mawawala. Ang isang overlay mount ay lumilikha ng isang unyon sa pagitan tmpfs at ang pinagbabatayan na file system at nagbibigay-daan sa iyong gumawa ng mga nakikitang pagbabago sa mga umiiral nang file sa ro-tootf samantalang ang isang bindable mount ay maaaring gawing walang laman ang mga bago tmpfs mga folder na nakikita bilang nasusulat sa ro-rootfs mga paraan. Habang overlayfs ito ang tama (proper) uri ng file system, ang bindable mount ay ipinatupad sa .
Batay sa paglalarawan ng overlay at linkable mount, walang nagulat na sila ay aktibong ginagamit. Tingnan natin kung ano ang mangyayari kapag ginamit natin upang patakbuhin ang lalagyan gamit ang tool mountsnoop mula sa bcc.
Hamon system-nspawn sinisimulan ang lalagyan habang tumatakbo mountsnoop.py.
Tingnan natin kung ano ang nangyari:
Ilunsad mountsnoop habang ang container ay "nagbo-boot" ay nagpapakita na ang runtime ng container ay lubos na nakadepende sa mount na naka-link (Tanging simula ng mahabang output ang ipinapakita).
Dito systemd-nspawn nagbibigay ng mga napiling file sa procfs и sysfs host sa lalagyan bilang mga landas patungo dito rootfs... Bukod sa MS_BIND flag na nagse-set up ng binding mount, ang ilang iba pang flag sa mount ay tumutukoy sa kaugnayan sa pagitan ng mga pagbabago sa host at mga namespace ng container. Halimbawa, maaaring laktawan ng isang naka-link na mount ang mga pagbabago sa /proc и /sys sa lalagyan, o itago ang mga ito depende sa tawag.
Konklusyon
Ang pag-unawa sa panloob na mga gawain ng Linux ay maaaring mukhang isang imposibleng gawain, dahil ang kernel mismo ay naglalaman ng isang malaking halaga ng code, na iniiwan ang mga Linux user space application at mga interface ng system call sa mga aklatan ng C tulad ng glibc. Ang isang paraan para umunlad ay basahin ang source code ng isang kernel subsystem, na may diin sa pag-unawa sa mga tawag sa system at mga header ng user-space, pati na rin ang mga pangunahing panloob na interface ng kernel, tulad ng talahanayan file_operations. Ang mga pagpapatakbo ng file ay nagbibigay ng "lahat ng bagay ay isang file" na prinsipyo, na ginagawang partikular na kasiya-siya na pamahalaan. C kernel source file sa top-level na direktoryo fs/ nagpapakita ng pagpapatupad ng mga virtual file system, na isang wrapper layer na nagbibigay ng malawak at medyo simpleng compatibility sa pagitan ng mga sikat na file system at storage device. Ang pag-link at pag-mount ng overlay sa pamamagitan ng mga namespace ng Linux ay ang magic ng VFS na ginagawang posible ang paglikha ng mga read-only na container at root filesystem. Kasama ng pagsusuri sa source code, ang eBPF core tool at ang interface nito bcc
ginagawang mas madali ang core exploration kaysa dati.
Mga kaibigan, sumulat, kapaki-pakinabang ba sa iyo ang artikulong ito? Marahil mayroon kang anumang mga komento o komento? At ang mga interesado sa kursong Linux Administrator ay iniimbitahan , na magaganap sa Abril 18.
Pinagmulan: www.habr.com