Hola a tots, compartim amb vosaltres la segona part de la publicació "Sistemas de fitxers virtuals a Linux: per què són necessaris i com funcionen?" Podeu llegir la primera part . Us recordem que aquesta sèrie de publicacions està programada per coincidir amb el llançament d'un nou flux al curs , que comença molt aviat.
Com controlar VFS mitjançant eBPF i eines bcc
La manera més senzilla d'entendre com funciona el nucli als fitxers sysfs és veure-ho a la pràctica, i la manera més fàcil de veure ARM64 és utilitzar eBPF. eBPF (abreviatura de Berkeley Packet Filter) consisteix en una màquina virtual que s'executa , que els usuaris privilegiats poden sol·licitar (query) des de la línia d'ordres. Les fonts del nucli diuen al lector què pot fer el nucli; executar les eines eBPF en un sistema carregat mostra què està fent realment el nucli.
Afortunadament, començar a utilitzar eBPF és bastant fàcil amb l'ajuda d'eines , que estan disponibles com a paquets de la distribució general i documentat detalladament . Eines bcc són scripts de Python amb petites insercions de codi C, la qual cosa significa que qualsevol persona que conegui ambdós idiomes els pot modificar fàcilment. EN bcc/tools Hi ha 80 scripts de Python, la qual cosa significa que molt probablement un desenvolupador o administrador del sistema podrà triar alguna cosa adequada per resoldre el problema.
Per tenir almenys una idea superficial del treball que fan els VFS en un sistema en execució, proveu-ho vfscount o vfsstat. Això mostrarà, diguem, que desenes de trucades vfs_open() i "els seus amics" passen literalment cada segon.
vfsstat.pyés un script Python amb insercions de codi C que simplement compta les trucades de funció VFS.
Posem un exemple més trivial i veiem què passa quan inserim una unitat flash USB a un ordinador i el sistema la detecta.
Amb eBPF podeu veure què està passant
/sysquan s'insereix una unitat flash USB. Aquí es mostra un exemple senzill i complex.
En l'exemple mostrat anteriorment, bcc инструмент imprimeix un missatge quan s'executa l'ordre sysfs_create_files(). Ho veiem sysfs_create_files() es va llançar utilitzant kworker stream en resposta al fet que s'ha inserit la unitat flaix, però quin fitxer s'ha creat? El segon exemple mostra el poder d'eBPF. Aquí trace.py Imprimeix una traça inversa del nucli (opció -K) i el nom del fitxer que s'ha creat sysfs_create_files(). La inserció d'una declaració única és un codi C que inclou una cadena de format fàcilment reconeixible proporcionada per l'script de Python que executa LLVM compilador just a temps. Compila aquesta línia i l'executa en una màquina virtual dins del nucli. Signatura de funció completa sysfs_create_files () s'ha de reproduir a la segona ordre perquè la cadena de format pugui fer referència a un dels paràmetres. Els errors en aquest fragment de codi C donen lloc a errors reconeixibles del compilador C. Per exemple, si s'omet el paràmetre -l, veureu "No s'ha pogut compilar el text BPF". Els desenvolupadors que estiguin familiaritzats amb C i Python trobaran les eines bcc fàcil d'ampliar i canviar.
Quan s'insereix la unitat USB, la traça enrere del nucli mostrarà que el PID 7711 és un fil kworkerque va crear el fitxer «events» в sysfs. En conseqüència, la trucada de sysfs_remove_files() mostrarà que l'eliminació de la unitat va provocar la supressió del fitxer events, que correspon al concepte general de recompte de referència. Al mateix temps, visualització sysfs_create_link () amb eBPF mentre inseriu la unitat USB mostrarà que s'han creat almenys 48 enllaços simbòlics.
Llavors, quin sentit té el fitxer d'esdeveniments? Ús Per a la recerca , mostra el que provoca disk_add_events (), i tampoc "media_change"O "eject_request" es pot gravar en un fitxer d'esdeveniments. Aquí la capa de blocs del nucli informa l'espai d'usuari que un "disc" ha aparegut i s'ha expulsat. Tingueu en compte com d'informatiu és aquest mètode d'investigació inserint una unitat USB, en comparació amb intentar esbrinar com funcionen les coses només des de la font.
Els sistemes de fitxers arrel de només lectura permeten els dispositius incrustats
Per descomptat, ningú apaga el servidor ni el seu ordinador traient l'endoll de la presa. Però perquè? Això es deu al fet que els sistemes de fitxers muntats en dispositius d'emmagatzematge físic poden tenir escriptures retardades i les estructures de dades que en registren l'estat poden no estar sincronitzades amb les escriptures a l'emmagatzematge. Quan això succeeix, els propietaris del sistema han d'esperar fins a la propera arrencada per iniciar la utilitat. fsck filesystem-recovery i, en el pitjor dels casos, perdre dades.
Tanmateix, tots sabem que molts dispositius IoT, així com encaminadors, termòstats i cotxes, ara funcionen amb Linux. Molts d'aquests dispositius tenen poca o cap interfície d'usuari i no hi ha manera d'apagar-los "netament". Imagineu-vos engegar un cotxe amb una bateria esgotada quan la unitat de control està alimentada saltant amunt i avall constantment. Com és que el sistema arrenca sense temps fsckquan finalment comença a funcionar el motor? I la resposta és senzilla. Els dispositius incrustats depenen del sistema de fitxers arrel (abreujat ro-rootfs (sistema de fitxers arrel només de lectura)).
ro-rootfs ofereixen molts avantatges que són menys evidents que l'autenticitat. Un avantatge és que el programari maliciós no pot escriure /usr o /lib, si cap procés de Linux pot escriure-hi. Un altre és que un sistema de fitxers en gran mesura immutable és fonamental per al suport de camp de dispositius remots, ja que el personal de suport es basa en sistemes locals que són nominalment idèntics als sistemes de camp. Potser el benefici més important (però també el més insidios) és que els ro-rootfs obliga els desenvolupadors a decidir quins objectes del sistema seran immutables en l'etapa de disseny del sistema. Treballar amb ro-rootfs pot ser incòmode i dolorós, ja que les variables const sovint es troben en llenguatges de programació, però els seus beneficis justifiquen fàcilment la sobrecàrrega addicional.
creació rootfs La lectura només requereix un esforç addicional per als desenvolupadors integrats, i aquí és on entra en escena VFS. Linux requereix que hi hagi fitxers /var eren escrivibles i, a més, moltes aplicacions populars que executen sistemes incrustats intentaran crear configuració dot-files в $HOME. Una solució per als fitxers de configuració al directori d'inici sol ser generar-los prèviament i incorporar-los rootfs. Per /var Un enfocament possible és muntar-lo en una partició escriptura separada, mentre / muntat només de lectura. Una altra alternativa popular és utilitzar suports d'enllaç o superposició.
Muntatges enganxables i apilables, el seu ús per contenidors
Executant una ordre man mount és la millor manera d'aprendre sobre muntatges enllaçables i superposables, que donen als desenvolupadors i administradors de sistemes la possibilitat de crear un sistema de fitxers en un camí i després exposar-lo a aplicacions en un altre. Per als sistemes incrustats, això significa la possibilitat d'emmagatzemar fitxers /var en una unitat flaix només de lectura, però una superposició o un camí de muntatge enllaçable tmpfs в /var quan es carregui, permetrà que les aplicacions hi escriguin notes (scrawl). La propera vegada que activeu els canvis a /var es perdran. Un suport superposat crea una unió entre ells tmpfs i el sistema de fitxers subjacent i us permet fer canvis ostensibles als fitxers existents a ro-tootf mentre que un muntatge lligable pot fer-ne buits de nous tmpfs carpetes visibles com a escrivibles a ro-rootfs maneres. Mentre overlayfs aquesta és la correcta (proper) tipus de sistema de fitxers, s'ha implementat el muntatge vinculable .
D'acord amb la descripció de la superposició i la muntura enllaçable, ningú no s'estranya s'utilitzen activament. A veure què passa quan fem servir per executar el contenidor amb l'eina mountsnoop d' bcc.
Desafiament system-nspawn inicia el contenidor mentre s'executa mountsnoop.py.
A veure què ha passat:
Запуск mountsnoop mentre el contenidor s'està "arrencant" mostra que el temps d'execució del contenidor depèn molt del muntatge que s'enllaça (només es mostra el començament de la sortida llarga).
Aquí systemd-nspawn proporciona fitxers seleccionats a procfs и sysfs host al contenidor com a camins cap a ell rootfs. A més MS_BIND indicador que configura el muntatge d'enllaç, alguns altres indicadors del muntatge defineixen la relació entre els canvis als espais de noms de l'amfitrió i del contenidor. Per exemple, un muntatge enllaçat pot ometre els canvis /proc и /sys al contenidor o amagar-los en funció de la trucada.
Conclusió
Entendre el funcionament intern de Linux pot semblar una tasca impossible, ja que el nucli en si conté una gran quantitat de codi, deixant de banda les aplicacions d'espai d'usuari de Linux i les interfícies de trucada del sistema a les biblioteques C, com ara glibc. Una manera d'avançar és llegir el codi font d'un subsistema del nucli, posant èmfasi en la comprensió de les trucades del sistema i les capçaleres de l'espai d'usuari, així com les principals interfícies internes del nucli, com ara la taula. file_operations. Les operacions de fitxers proporcionen el principi "tot és un fitxer", cosa que les fa especialment agradables de gestionar. Fitxers font del nucli C al directori de nivell superior fs/ presenten una implementació de sistemes de fitxers virtuals, que són una capa d'embolcall que ofereix una compatibilitat àmplia i relativament senzilla entre sistemes de fitxers i dispositius d'emmagatzematge populars. L'enllaç i el muntatge de superposició mitjançant espais de noms Linux és la màgia de VFS que permet crear contenidors de només lectura i sistemes de fitxers arrel. Combinat amb un examen del codi font, l'eina bàsica eBPF i la seva interfície bcc
fent que l'exploració del nucli sigui més fàcil que mai.
Amics, escriviu, us ha estat útil aquest article? Potser tens algun comentari o comentari? I els que estiguin interessats en el curs d'Administrador de Linux hi estan convidats , que tindrà lloc el 18 d'abril.
Font: www.habr.com