Helo bawb, rydym yn rhannu gyda chi ail ran y cyhoeddiad “Systemau ffeiliau rhithwir yn Linux: pam mae eu hangen a sut maen nhw'n gweithio?” Gallwch ddarllen y rhan gyntaf . Gadewch inni eich atgoffa bod y gyfres hon o gyhoeddiadau wedi'i hamseru i gyd-fynd â lansiad ffrwd newydd ar y cwrs , sy'n dechrau'n fuan iawn.
Sut i fonitro VFS gan ddefnyddio offer eBPF a bcc
Y ffordd hawsaf i ddeall sut mae'r cnewyllyn yn gweithredu ar ffeiliau sysfs yw ei weld yn ymarferol, a'r ffordd hawsaf i wylio ARM64 yw defnyddio eBPF. Mae eBPF (sy'n fyr ar gyfer Berkeley Packet Filter) yn cynnwys peiriant rhithwir sy'n rhedeg i mewn , y gall defnyddwyr breintiedig ofyn amdano (query) o'r llinell orchymyn. Mae'r ffynonellau cnewyllyn yn dweud wrth y darllenydd beth all y cnewyllyn ei wneud; mae rhedeg yr offer eBPF ar system wedi'i llwytho yn dangos beth mae'r cnewyllyn yn ei wneud mewn gwirionedd.
Yn ffodus, mae dechrau defnyddio eBPF yn eithaf hawdd gyda chymorth offer , sydd ar gael fel pecynnau o'r dosbarthiad cyffredinol ac wedi'u dogfennu'n fanwl . Offer bcc yn sgriptiau Python gyda mewnosodiadau bach o god C, sy'n golygu y gall unrhyw un sy'n gyfarwydd â'r ddwy iaith eu haddasu'n hawdd. YN bcc/tools Mae yna 80 o sgriptiau Python, sy'n golygu ei bod yn debygol y bydd datblygwr neu weinyddwr system yn gallu dewis rhywbeth sy'n addas ar gyfer datrys y broblem.
I gael o leiaf syniad arwynebol o ba waith mae VFSs yn ei wneud ar system redeg, ceisiwch vfscount neu vfsstat. Bydd hyn yn dangos, gadewch i ni ddweud, bod dwsinau o alwadau vfs_open() ac mae “ei ffrindiau” yn digwydd yn llythrennol bob eiliad.
vfsstat.pyyn sgript Python gyda mewnosodiadau cod C sy'n cyfrif galwadau swyddogaeth VFS yn syml.
Gadewch i ni roi enghraifft fwy dibwys a gweld beth sy'n digwydd pan fyddwn yn mewnosod gyriant fflach USB i mewn i gyfrifiadur a bod y system yn ei ganfod.
Gan ddefnyddio eBPF gallwch weld beth sy'n digwydd ynddo
/syspan fydd gyriant fflach USB yn cael ei fewnosod. Dangosir enghraifft syml a chymhleth yma.
Yn yr enghraifft a ddangosir uchod, bcc инструмент yn argraffu neges pan fydd y gorchymyn yn cael ei redeg sysfs_create_files(). Rydym yn gweld hynny sysfs_create_files() ei lansio gan ddefnyddio kworker ffrwd mewn ymateb i'r ffaith bod y gyriant fflach wedi'i fewnosod, ond pa ffeil a grëwyd? Mae'r ail enghraifft yn dangos pŵer eBPF. Yma trace.py Yn argraffu ôl-olrhain cnewyllyn (opsiwn -K) ac enw'r ffeil a grëwyd sysfs_create_files(). Mewnosod datganiad sengl yw cod C sy'n cynnwys llinyn fformat hawdd ei adnabod a ddarperir gan y sgript Python sy'n rhedeg LLVM casglwr mewn union bryd. Mae'n llunio'r llinell hon a'i gweithredu mewn peiriant rhithwir y tu mewn i'r cnewyllyn. Llofnod swyddogaeth lawn sysfs_create_files () rhaid ei atgynhyrchu yn yr ail orchymyn fel y gall y llinyn fformat gyfeirio at un o'r paramedrau. Mae gwallau yn y darn hwn o god C yn arwain at wallau adnabyddadwy o'r casglwr C. Er enghraifft, os yw'r paramedr -l yn cael ei hepgor, fe welwch "Wedi methu llunio testun BPF." Bydd datblygwyr sy'n gyfarwydd â C a Python yn dod o hyd i'r offer bcc hawdd ei ehangu a'i newid.
Pan fewnosodir y gyriant USB, bydd ôl-olrhain y cnewyllyn yn dangos bod PID 7711 yn edau kworkera greodd y ffeil «events» в sysfs. Yn unol â hynny, mae'r alwad gan sysfs_remove_files() yn dangos bod dileu'r gyriant wedi arwain at ddileu'r ffeil events, sy'n cyfateb i'r cysyniad cyffredinol o gyfri. Ar yr un pryd, gwylio sysfs_create_link () gydag eBPF tra bydd mewnosod y gyriant USB yn dangos bod o leiaf 48 o gysylltiadau symbolaidd wedi'u creu.
Felly beth yw pwynt y ffeil digwyddiadau? Defnydd Ar gyfer chwilio , yn dangos beth mae'n ei achosi disk_add_events (), a naill ai "media_change"Neu "eject_request" gellir ei gofnodi mewn ffeil digwyddiad. Yma mae'r haen bloc cnewyllyn yn hysbysu gofod defnyddwyr bod "disg" wedi ymddangos ac wedi'i daflu allan. Sylwch pa mor addysgiadol yw'r dull ymchwil hwn trwy fewnosod gyriant USB, o'i gymharu â cheisio darganfod sut mae pethau'n gweithio o'r ffynhonnell yn unig.
Mae systemau ffeiliau gwraidd darllen yn unig yn galluogi dyfeisiau wedi'u mewnosod
Wrth gwrs, nid oes neb yn diffodd y gweinydd na'u cyfrifiadur trwy dynnu'r plwg o'r soced. Ond pam? Mae hyn oherwydd y gallai systemau ffeiliau wedi'u gosod ar ddyfeisiau storio ffisegol fod wedi llusgo ysgrifen, ac efallai na fydd y strwythurau data sy'n cofnodi eu cyflwr wedi'u cysoni ag ysgrifenniadau i'r storfa. Pan fydd hyn yn digwydd, mae'n rhaid i berchnogion systemau aros tan y cychwyn nesaf i lansio'r cyfleustodau. fsck filesystem-recovery ac, yn yr achos gwaethaf, colli data.
Fodd bynnag, rydym i gyd yn gwybod bod llawer o ddyfeisiau IoT, yn ogystal â llwybryddion, thermostatau a cheir, bellach yn rhedeg Linux. Nid oes gan lawer o'r dyfeisiau hyn fawr ddim rhyngwyneb defnyddiwr, ac nid oes unrhyw ffordd i'w diffodd yn "lân." Dychmygwch ddechrau car gyda batri marw pan fydd y pŵer i'r uned reoli neidio i fyny ac i lawr yn gyson. Sut mae'r system yn cychwyn heb hir fsckpryd mae'r injan yn dechrau rhedeg o'r diwedd? Ac mae'r ateb yn syml. Mae dyfeisiau wedi'u mewnblannu yn dibynnu ar y system ffeiliau gwraidd (cryno ro-rootfs (system ffeil gwraidd darllen yn unig)).
ro-rootfs cynnig llawer o fanteision sy'n llai amlwg na dilysrwydd. Un fantais yw na all malware ysgrifennu ato /usr neu /lib, os na all unrhyw broses Linux ysgrifennu yno. Un arall yw bod system ffeiliau ddigyfnewid i raddau helaeth yn hanfodol ar gyfer cynnal dyfeisiau o bell yn y maes, gan fod personél cymorth yn dibynnu ar systemau lleol sydd, mewn enw, yn union yr un fath â'r systemau maes. Efallai mai'r budd pwysicaf (ond hefyd y mwyaf llechwraidd) yw bod ro-rootfs yn gorfodi datblygwyr i benderfynu pa wrthrychau system fydd yn ddigyfnewid yn ystod cam dylunio'r system. Gall gweithio gyda ro-rootfs fod yn lletchwith ac yn boenus, gan fod newidynnau const yn aml mewn ieithoedd rhaglennu, ond mae eu buddion yn cyfiawnhau'r gorbenion ychwanegol yn hawdd.
creu rootfs Mae darllen yn unig yn gofyn am rywfaint o ymdrech ychwanegol ar gyfer datblygwyr sydd wedi'u mewnosod, a dyma lle mae VFS yn dod i mewn i'r llun. Mae Linux yn mynnu bod ffeiliau i mewn /var yn ysgrifenadwy, ac yn ogystal, bydd llawer o gymwysiadau poblogaidd sy'n rhedeg systemau wedi'u mewnosod yn ceisio creu cyfluniad dot-files в $HOME. Un ateb ar gyfer ffeiliau ffurfweddu yn y cyfeiriadur cartref fel arfer yw eu rhag-gynhyrchu a'u cynnwys rootfs. I /var Un dull posibl yw ei osod ar raniad ysgrifenadwy ar wahân, tra / wedi'i fowntio darllen-yn-unig. Dewis arall poblogaidd yw defnyddio mowntiau rhwymo neu droshaenu.
Mowntiau y gellir eu cysylltu a'u stacio, a'u defnydd gan gynwysyddion
Gweithredu gorchymyn man mount yw'r ffordd orau o ddysgu am fowntiau rhwymadwy a throshaenadwy, sy'n rhoi'r gallu i ddatblygwyr a gweinyddwyr system greu system ffeiliau mewn un llwybr ac yna ei hamlygu i gymwysiadau mewn un arall. Ar gyfer systemau wedi'u mewnosod, mae hyn yn golygu'r gallu i storio ffeiliau i mewn /var ar yriant fflach darllen yn unig, ond troshaen neu lwybr mowntio cysylltadwy o tmpfs в /var wrth lwytho, bydd yn caniatáu i gymwysiadau ysgrifennu nodiadau yno (sgriwio). Y tro nesaf y byddwch chi'n troi'r newidiadau ymlaen i /var bydd yn cael ei golli. Mae mownt troshaen yn creu undeb rhwng tmpfs a'r system ffeiliau sylfaenol ac yn eich galluogi i wneud newidiadau gweladwy i'r ffeiliau presennol yn ro-tootf tra gall mownt rhwymadwy wneud rhai newydd yn wag tmpfs ffolderi i'w gweld fel rhai y gellir eu hysgrifennu ynddynt ro-rootfs ffyrdd. Tra overlayfs dyma'r un iawn (proper) math o system ffeiliau, mownt rhwymadwy yn cael ei weithredu yn .
Yn seiliedig ar y disgrifiad o'r troshaen a'r mownt y gellir ei gysylltu, nid oes neb yn synnu hynny maent yn cael eu defnyddio'n weithredol. Gawn ni weld beth sy'n digwydd pan fyddwn ni'n defnyddio i redeg y cynhwysydd gan ddefnyddio'r offeryn mountsnoop o bcc.
Her system-nspawn yn dechrau'r cynhwysydd wrth redeg mountsnoop.py.
Gawn ni weld beth ddigwyddodd:
Запуск mountsnoop tra bod y cynhwysydd yn "booting" yn dangos bod amser rhedeg y cynhwysydd yn dibynnu'n fawr ar y mownt yn cael ei gysylltu (Dim ond dechrau'r allbwn hir a ddangosir).
Yma systemd-nspawn yn darparu ffeiliau dethol yn procfs и sysfs gwesteiwr i gynhwysydd fel llwybrau iddo rootfs. Eithr MS_BIND baner sy'n sefydlu'r mownt rhwymo, mae rhai baneri eraill ar y mownt yn diffinio'r berthynas rhwng newidiadau i ofodau enwau'r gwesteiwr a'r cynhwysydd. Er enghraifft, gall mownt cysylltiedig naill ai hepgor newidiadau i /proc и /sys i mewn i'r cynhwysydd, neu guddio nhw yn dibynnu ar yr alwad.
Casgliad
Gall deall gwaith mewnol Linux ymddangos yn dasg amhosibl, gan fod y cnewyllyn ei hun yn cynnwys llawer iawn o god, gan adael cymwysiadau gofod defnyddiwr Linux a rhyngwynebau galwadau system o'r neilltu mewn llyfrgelloedd C fel glibc. Un ffordd o wneud cynnydd yw darllen cod ffynhonnell un is-system cnewyllyn, gyda phwyslais ar ddeall galwadau system a phenawdau gofod defnyddiwr, yn ogystal â'r prif ryngwynebau cnewyllyn mewnol, megis tabl file_operations. Mae gweithrediadau ffeil yn darparu'r egwyddor "mae popeth yn ffeil", gan eu gwneud yn arbennig o bleserus i'w rheoli. C ffeiliau ffynhonnell cnewyllyn yn y cyfeiriadur lefel uchaf fs/ cyflwyno gweithrediad systemau ffeiliau rhithwir, sef haen lapio sy'n darparu cydnawsedd eang a chymharol syml rhwng systemau ffeiliau poblogaidd a dyfeisiau storio. Cysylltu a gosod troshaenau trwy ofodau enwau Linux yw hud VFS sy'n ei gwneud yn bosibl creu cynwysyddion darllen yn unig a systemau ffeiliau gwraidd. Ar y cyd ag archwiliad o'r cod ffynhonnell, yr offeryn craidd eBPF a'i ryngwyneb bcc
gwneud archwilio craidd yn haws nag erioed.
Gyfeillion, ysgrifennwch, a oedd yr erthygl hon yn ddefnyddiol i chi? Efallai bod gennych chi unrhyw sylwadau neu sylwadau? A gwahoddir y rhai sydd â diddordeb yn y cwrs Gweinyddwr Linux i , a fydd yn digwydd ar Ebrill 18.
Ffynhonnell: hab.com