Ja saps què és un sistema operatiu, d'on ve i de quins tipus n'hi ha. Toca ara obrir la caixa i veure què fa exactament. Aquesta lliçó és el mapa de la resta del curs: cada gran funció que hi vegis correspon a un o diversos mòduls posteriors, i la veuràs aplicada a una situació concreta de Meteora. Però l'objectiu no és que et quedis amb una llista de set funcions soltes, perquè a la realitat no actuen mai per separat: atendre una sola petició HTTP a meteo-api mobilitza totes en qüestió de mil·lisegons. Per això tancarem seguint el cicle de vida complet d'una petició, de cap a cap, per veure com cooperen.

1. Gestió de processos i del processador
2. Gestió de memòria
3. Gestió de l'emmagatzematge i de fitxers
4. Gestió de dispositius i d'entrada/sortida
5. Gestió de la xarxa
6. Protecció i seguretat
7. Interfície d'usuari: shell i entorn gràfic
8. Totes alhora: cicle de vida d'una petició a meteo-api

Què fa. Crear processos, destruir-los, suspendre'ls, reprendre'ls, mantenir informació de cadascun i decidir quin d'ells ocupa la CPU a cada instant. El sistema manté per a cada procés una estructura de control (a Linux, task_struct) amb el seu identificador, el seu estat, els seus registres desats, la seva taula de fitxers oberts, el seu usuari propietari i les seves estadístiques de consum.

Per què és difícil. Perquè meteo-01 té 4 nuclis i, en un moment qualsevol, 300 processos. Hi ha 300 candidats per a 4 places, i la decisió s'ha de prendre milers de vegades per segon, en microsegons, sense conèixer el futur i sense afavorir sistemàticament ningú.

A Meteora. Quan agregador engega el seu càlcul de les 02:30, consumeix un nucli sencer durant 20 segons. Si el sistema no hi intervingués, meteo-api quedaria sense CPU durant aquest temps i tots els clients veurien temps d'espera. El que passa en realitat és que el planificador apropia agregador cada pocs mil·lisegons i dona pas a meteo-api tan bon punt arriba una petició.

Interpretació columna a columna:

• NI és el valor nice: la cortesia del procés, de −20 (prioritat màxima) a +19 (mínima). agregador té 10, cosa que significa que s'ha arrencat deliberadament amb prioritat baixa perquè no molesti el servei.
• PRI és la prioritat efectiva calculada pel nucli.
• STAT és l'estat: S significa sleeping (bloquejat esperant alguna cosa, típicament E/S), R running o llest per executar-se, i la l de Sl indica que el procés té diversos fils.
• ETIMES són els segons transcorreguts des que va arrencar. ingestor i meteo-api fa 864.320 segons (10 dies) que corren; agregador acaba de començar.

Fixa't en el patró: els dos serveis permanents estan adormits gairebé tot el temps, esperant xarxa. agregador s'està executant. Aquest perfil (S per a serveis, R per a feines de càlcul) és el primer que es mira quan es diagnostica un servidor.

On es desenvolupa. Gestió de Processos i Planificació de la CPU. La concurrència entre processos i fils ocupa el mòdul 3 sencer.

Què fa. Decidir què hi ha a la RAM i on, assignar i alliberar memòria als processos, donar a cadascun un espai d'adreces privat, i fer que hi càpiga més del que físicament hi ha.

Per què és difícil. La RAM és un recurs escàs, indivisible en la seva forma física i compartit per tothom. Tres exigències entren en conflicte: que els processos no es trepitgin, que s'aprofiti cada byte, i que tot això no costi temps.

A Meteora. meteo-api té un consum curiós que convé entendre:

• VSZ (Virtual Size) són els KB d'espai d'adreces virtual: 1.284.560 KB, uns 1,2 GB.
• RSS (Resident Set Size) són els KB que realment ocupen RAM física: 47.320 KB, uns 46 MB.

La diferència és de 27 vegades, i no és cap error. meteo-api ha reservat espai d'adreces per a moltes coses (biblioteques compartides, regions mapades, piles dels seus fils) que no està fent servir ara mateix, i el sistema no li ha donat memòria física per a elles. El sistema lliura memòria física només quan el procés toca de debò aquestes adreces. Aquest mecanisme, l'assignació mandrosa, és la raó que a meteo-01 amb 8 GB de RAM hi puguin conviure processos la suma de VSZ dels quals supera els 20 GB.

Un error de principiant molt car: alarmar-se pel VSZ. La columna que importa per saber si et quedes sense memòria és RSS, i ni tan sols aquesta del tot, perquè part de la memòria resident són biblioteques compartides comptabilitzades en diversos processos alhora.

On es desenvolupa. Gestió de Memòria i Memòria Virtual i Paginació.

Què fa. Convertir un dispositiu que només entén de blocs numerats en un arbre de directoris amb fitxers que tenen nom, mida, dates, propietari i permisos. A més: assignar espai, gestionar l'espai lliure, mantenir la coherència davant d'un tall de llum i desar a la memòria cau de la RAM el que s'ha llegit recentment.

Per què és difícil. Perquè el disc no sap res de fitxers. Un SSD ofereix una seqüència de blocs de 4 KB numerats del 0 al que sigui. Tota la resta —noms, jerarquia, permisos, la noció mateixa de «fitxer»— és una estructura de dades que el sistema operatiu construeix a sobre i ha de mantenir coherent encara que la màquina s'apagui en el pitjor moment possible.

A Meteora. Els fitxers diaris de lectures viuen a /var/lib/meteora/lectures/:

Què ens diu això:

• ls -lh mostra el llistat llarg amb mides llegibles (-h). El fitxer d'avui té 12 MB perquè el dia encara no s'ha acabat: creix a raó d'uns 24 bytes per lectura rebuda.
• Els permisos -rw-r----- signifiquen: el propietari (meteora) llegeix i escriu, el grup (meteora) només llegeix, i la resta del món no hi té cap accés. Qualsevol altre usuari del sistema no en pot ni tan sols veure el contingut.
• df -h informa del sistema de fitxers que conté aquesta ruta: el dispositiu /dev/sda2, muntat a /var, amb un 63 % d'ocupació.

Aquest 63 % és una dada operativa important: a 17 MB diaris, queden 72 GB lliures, és a dir, uns 11 anys de dades. Però si demà Meteora doblés el nombre d'estacions i guardés a més dades derivades, aquest marge es reduiria ràpidament. Vigilar el creixement forma part de la feina, i per això ho veurem a Monitoratge i Diagnòstic de Rendiment.

On es desenvolupa. Mòdul 4 sencer, començant per Sistemes de Fitxers i Gestió d'Emmagatzematge.

Què fa. Oferir una interfície uniforme per a maquinari molt divers, mitjançant controladors (drivers) específics; planificar les operacions d'E/S; atendre les interrupcions que generen els dispositius; i esmorteir la diferència de velocitat entre la CPU i tota la resta amb memòries intermèdies i memòries cau.

Per què és difícil. Per la desproporció de velocitats que ja has vist: mentre el disc atén una petició de 50 µs, la CPU podria executar unes 150.000 instruccions. Si la CPU esperés activament, es malbarataria. La solució —bloquejar el procés, executar-ne un altre, i despertar el primer mitjançant una interrupció quan la dada arribi— és el cor del disseny d'un sistema operatiu.

A Meteora. ingestor rep unes 500 lectures per minut de la xarxa i les escriu al disc. Si cada lectura provoqués una escriptura física, serien 500 operacions de disc per minut per escriure 12 KB en total: absurd. El sistema agrupa aquestes escriptures a la memòria cau de pàgines i les aboca al disc en blocs més grans.

Explicació de cada línia:

• MemTotal: 8 GB de RAM a la màquina.
• MemFree: només 400 MB lliures. Això no és cap problema, i confondre-ho amb un problema és l'error més freqüent de tots.
• Cached: 5,2 GB dedicats a memòria cau de pàgines, és a dir, còpies a la RAM de dades de fitxers. Aquesta memòria és recuperable a l'instant: si un procés la necessita, el nucli l'allibera. Els fitxers de lectures dels últims dies són aquí, i per això agregador els rellegeix tan de pressa.
• Dirty: 8 MB escrits per processos que encara no han arribat al disc. Són les dades que ingestor ha lliurat i el nucli encara no ha abocat.
• Writeback: 0 KB en trànsit cap al disc en aquest instant.

Aquest valor Dirty és també un risc: si meteo-01 perdés el corrent ara mateix, aquests 8 MB de lectures es perdrien. Quan la pèrdua és inacceptable, el programa ha de forçar l'abocament amb fsync(), a costa de rendiment. És un compromís clàssic que reprendrem a Assignació d'Espai, Journaling i Integritat.

On es desenvolupa. Gestió de Dispositius i Controladors, Interrupcions i Operacions d'E/S.

Què fa. Implementar les piles de protocols (TCP/IP), gestionar les interfícies, mantenir les taules de rutes, multiplexar les connexions entre processos i oferir l'abstracció de sòcol, que permet tractar una connexió remota gairebé com un fitxer.

Per què és una funció del sistema operatiu i no de l'aplicació. Perquè la targeta de xarxa és un recurs compartit: meteo-api, ingestor i sshd estan tots escoltant alhora, i algú ha de decidir a qui correspon cada paquet que arriba. Aquest repartiment es fa per port, i només el nucli el pot arbitrar.

A Meteora.

Anàlisi línia a línia:

• ss -tlnp llista sòcols TCP (-t) en escolta (-l), sense resoldre noms (-n, més ràpid i sense sorpreses de DNS) i mostrant el procés propietari (-p).
• meteo-api escolta a 0.0.0.0:8080: l'adreça 0.0.0.0 significa totes les interfícies, és a dir, accepta connexions des de fora de la màquina. És el que toca per a un servei públic.
• ingestor escolta a 127.0.0.1:9310: només a la interfície de bucle local, així que únicament processos de la mateixa màquina s'hi poden connectar. És una decisió de seguretat deliberada. Si hagués d'acceptar connexions de les estacions des de fora, aquest seria un port exposat i s'hauria de protegir.
• Send-Q en estat LISTEN indica la mida màxima de la cua de connexions pendents: 512 per a meteo-api, 128 per a ingestor. Si arriben més connexions simultànies de les que caben en aquesta cua, es rebutgen.
• fd=6 i fd=4 són els descriptors de fitxer d'aquests sòcols dins de cada procés: la prova directa que «tot és un fitxer» arriba també a la xarxa.

Què fa. Autenticar (qui ets?), autoritzar (pots fer això?), aïllar (que un procés no toqui allò que és d'un altre) i auditar (deixar constància del que ha passat).

Convé separar dos conceptes que se solen barrejar:

• Protecció és el mecanisme intern que impedeix que els processos interfereixin entre si, fins i tot sense mala intenció. Que una fallada a agregador no corrompi la memòria de meteo-api és protecció.
• Seguretat és la defensa davant d'un adversari que actua amb intenció. Que un atacant que compromet meteo-api no pugui llegir /etc/shadow és seguretat.

A Meteora. El model de permisos aplica el privilegi mínim a cada capa:

L'interessant és als detalls:

• El fitxer de configuració pertany a root però el seu grup és meteora. Els serveis el poden llegir (permís r de grup) però no modificar, perquè el permís d'escriptura és només del propietari root. Si un atacant compromet meteo-api, no pot alterar la configuració per, per exemple, canviar la ruta de les dades.
• El registre sí que pertany a meteora, perquè el servei hi ha d'escriure.
• uid=990: els identificadors per sota de 1000 es reserven per convenció a comptes de sistema, que no corresponen a persones i no poden iniciar sessió interactiva.

On es desenvolupa. Mòdul 5 sencer, més Seguretat i Permisos de Fitxers.

Què fa. Oferir una via perquè les persones donin ordres al sistema. Pot ser una línia de comandes (bash), un entorn gràfic (GNOME) o una API d'administració remota.

Matís essencial, ja vist a la primera lliçó. La interfície no forma part del nucli. bash és un programa d'usuari que llegeix el que escrius, ho interpreta i demana al nucli que executi programes mitjançant crides al sistema. El seu privilegi és exactament el mateix que el de qualsevol altre programa de l'usuari.

A meteo-01 no hi ha entorn gràfic. Tota l'administració es fa per SSH i amb bash, i això és deliberat: menys programari instal·lat significa menys memòria consumida, menys actualitzacions per aplicar i menys vulnerabilitats potencials.

On es desenvolupa. La Línia de Comandes com a Interfície del Sistema.

Aquí és on les set funcions deixen de ser una llista i es converteixen en un sistema. Seguim una petició real:

Recorrem el diagrama posant nom a la funció responsable de cada pas:

1. Arribada per xarxa (gestió de la xarxa + gestió de dispositius). La targeta rep els paquets i llança una interrupció. El nucli reassembla el flux TCP, mira el port de destinació (8080) i localitza el sòcol de meteo-api.
2. Despertar i planificar (gestió de processos). meteo-api estava bloquejat a read(), en estat S. El nucli el passa a «llest» i el planificador decideix quan li dona CPU. Com que és un procés orientat a E/S, té avantatge respecte d'agregador. El canvi de context costa de l'ordre d'1 a 5 microsegons.
3. Lectura de la petició (crides al sistema, tema de la lliçó següent). meteo-api executa read(), travessa la frontera cap a mode nucli, recull els seus bytes i torna.
4. Obertura del fitxer (gestió de fitxers + seguretat). El nucli tradueix /var/lib/meteora/lectures/2026-08-31.dat recorrent l'arbre de directoris, i a cada pas comprova que l'usuari meteora hi té permís. Si no en tingués, retornaria EACCES sense arribar a tocar el disc.
5. Obtenció de les dades (gestió de memòria + gestió de dispositius). Aquí hi ha dos camins, i la diferència entre tots dos és de tres ordres de magnitud:
   • Si els blocs són a la memòria cau de pàgines, la còpia es fa des de la RAM: uns 80 ns per bloc.
   • Si no hi són, el nucli demana els blocs al disc, bloqueja meteo-api i aprofita per executar un altre procés. Quan el disc acaba, llança una interrupció, el nucli copia les dades a la memòria cau de pàgines i desperta el procés: uns 50 µs per bloc en un SSD.
6. Càlcul (gestió de processos). meteo-api filtra les lectures de l'estació 118, agrupa per hora i calcula mitjanes. És l'única part del recorregut que fa feina específica de Meteora; tota la resta l'aporta el sistema.
7. Resposta (gestió de la xarxa). write() al sòcol. El nucli copia les dades a la seva memòria intermèdia de transmissió, les fragmenta segons la mida màxima de segment i ordena a la targeta que les enviï. Fixa't en un detall important: write() retorna el control abans que les dades hagin arribat al client. L'aplicació no espera la xarxa.
8. Registre (gestió de fitxers). Una altra escriptura, aquesta vegada a /var/log/meteora/meteo-api.log, que també passa per la memòria cau i s'abocarà al disc més tard.

La conclusió que importa: de tot aquest recorregut, el codi de Meteora només aporta el pas 6. Els set restants són sistema operatiu. I cap de les seves funcions no podria complir la seva part sense les altres: la planificació depèn de saber qui està bloquejat en E/S, l'E/S depèn de la gestió de memòria per a la memòria cau, la memòria cau depèn que la seguretat ja hagi autoritzat l'accés. Són un sistema, no un catàleg.

• Memoritzar les funcions com una llista. El que es pregunta a la pràctica no és «enumera les funcions del SO», sinó «per què aquesta petició triga 400 ms». Practica el recorregut del cicle de vida complet: és l'exercici que de debò ensenya.
• Alarmar-se perquè MemFree és baix. La RAM lliure no utilitzada és RAM malbaratada. Un sistema sa fa servir gairebé tota la memòria, la major part en memòria cau de pàgines, que s'allibera a l'instant quan cal. La mètrica útil és MemAvailable, no MemFree.
• Confondre VSZ amb consum real. L'espai d'adreces virtual pot ser 30 vegades més gran que la memòria física ocupada. Mira RSS, i per a una anàlisi fina, /proc/<pid>/smaps_rollup.
• Creure que l'aplicació «escriu al disc». L'aplicació lliura bytes al nucli. Quan arriben al disc ho decideix el sistema, tret que es forci amb fsync(). Aquesta diferència explica moltíssimes pèrdues de dades després d'un tall de llum.
• Pensar que write() a un sòcol significa que el client ha rebut les dades. Només significa que el nucli les ha acceptades a la seva memòria intermèdia de sortida.
• Consell: acostuma't a mirar les quatre coses bàsiques quan diagnostiquis qualsevol problema, en aquest ordre: estat dels processos (ps, top), memòria (free -h), disc (df -h, iostat) i xarxa (ss). Gairebé tots els incidents es localitzen aquí en menys d'un minut.

Per a cada símptoma observat a meteo-01, indica quina funció del sistema operatiu hi està implicada principalment, quina comanda faries servir per confirmar-ho i en quin mòdul del curs s'estudia:

1. Les respostes de meteo-api triguen 3 segons en comptes de 50 ms, i top mostra un nucli al 100 %.
2. ingestor falla amb «No space left on device».
3. Un client no es pot connectar al port 8080 des de fora, però des de la mateixa màquina sí.
4. meteo-api no pot llegir /etc/meteora/meteora.conf després d'un canvi de configuració.

meteo-api rep 200 peticions per segon. Cada petició requereix llegir 40 blocs de 4 KB del fitxer del dia. Calcula el temps total d'E/S per segon en dos escenaris: (a) tot des del disc SSD, a 50 µs per bloc; (b) tot des de la memòria cau de pàgines, a 80 ns per bloc. Pot meteo-01 sostenir aquesta càrrega en l'escenari (a)? Raona quina funció del SO fa que a la pràctica l'escenari real s'assembli al (b).

Recorre el cicle de vida d'una petició i indica, per a cadascun dels vuit passos, què passaria si aquella funció del sistema operatiu no existís. L'objectiu és que justifiquis la necessitat de cadascuna, no que en descriguis el funcionament.

Solució 1

1. Respostes lentes amb un nucli al 100 %

• Funció: gestió de processos i del processador. Hi ha contenció de CPU: algun procés (molt probablement agregador) està monopolitzant un nucli i meteo-api no rep prou CPU.
• Comanda: top ordenat per CPU, o ps -eo pid,ni,pri,stat,%cpu,comm --sort=-%cpu. Interessa mirar el valor NI: si agregador no s'ha arrencat amb nice, aquesta és la causa i la solució immediata és renice.
• Mòdul: Planificació de la CPU.

2. «No space left on device»

• Funció: gestió de l'emmagatzematge i de fitxers.
• Comanda: df -h /var/lib/meteora per veure l'espai, i també df -i. Aquest segon és important: l'error idèntic apareix quan s'esgoten els inodes encara que quedi espai lliure, cosa típica quan hi ha milions de fitxers petits. És un diagnòstic que es passa per alt constantment.
• Mòdul: Sistemes de Fitxers i Assignació d'Espai, Journaling i Integritat.

3. Connecta des de dins però no des de fora

• Funció: gestió de la xarxa (i possiblement seguretat, si hi ha tallafocs).
• Comanda: ss -tlnp | grep 8080. Si l'adreça local és 127.0.0.1:8080 en comptes de 0.0.0.0:8080, el servei només escolta al bucle local i aquest és el problema; es corregeix a la configuració de l'aplicació. Si ja escolta a 0.0.0.0, llavors cal revisar el tallafocs amb iptables -L -n o nft list ruleset.
• Mòdul: Amenaces Habituals i Enfortiment del Sistema per a la part de tallafocs.

4. No pot llegir la configuració

• Funció: protecció i seguretat.
• Comanda: ls -l /etc/meteora/meteora.conf i ls -ld /etc/meteora. Cal mirar-los tots dos: encara que el fitxer tingui permisos correctes, si el directori ha perdut el permís d'execució (x) per al grup, no es pot travessar i l'accés falla igualment. És l'error més freqüent quan s'ajusten permisos a mà.
• Mòdul: Seguretat i Permisos de Fitxers.

Solució 2

Blocs per llegir per segon:

(a) Des de l'SSD, a 50 µs per bloc:

(b) Des de la memòria cau de pàgines, a 80 ns per bloc:

Pot sostenir la càrrega en (a)? Estrictament sí, perquè 0,4 s d'E/S per cada segon de rellotge deixa marge. Però el marge és enganyós per dues raons:

• És un 65 % d'utilització efectiva del subsistema d'E/S si considerem la latència serialitzada. En teoria de cues, la latència creix de manera no lineal en acostar-se a la saturació: a partir del 70-80 % d'utilització, els temps de resposta es disparen. Un pic del doble de trànsit faria inviable el servei.
• Els 0,4 s són latència d'espera, no CPU. Durant aquest temps els processos estan bloquejats, cosa que exigeix que hi hagi prou fils o processos concurrents perquè el servidor no quedi aturat esperant.

Què fa que el cas real s'assembli a (b): la memòria cau de pàgines, que és gestió de memòria i d'E/S treballant juntes. Com que el fitxer del dia ocupa 17 MB i meteo-01 té gigabytes dedicats a memòria cau, després de les primeres lectures el fitxer complet resideix a la RAM i totes les peticions posteriors se serveixen des d'allà. El disc només hi intervé la primera vegada i al principi de cada dia nou.

Aquesta és també la raó que les proves de rendiment mal fetes donin resultats enganyosament bons: si mesures després d'haver executat la mateixa consulta vint vegades, estàs mesurant la RAM, no el sistema complet.

Solució 3

1. Sense gestió de xarxa: cada aplicació hauria de parlar directament amb la targeta i implementar TCP pel seu compte. Encara pitjor, no hi hauria manera de repartir els paquets entrants entre meteo-api, ingestor i sshd: només un programa podria fer servir la xarxa alhora.
2. Sense planificació de processos: meteo-api no podria ser despertat. O bé hauria de consultar activament el sòcol en un bucle (cremant CPU sense fer res útil) o bé el sistema executaria un sol programa fins que acabés, i les peticions s'atendrien d'una en una.
3. Sense crides al sistema: no hi hauria frontera entre l'aplicació i el nucli. Qualsevol programa podria manipular el maquinari directament, i una fallada a meteo-api podria corrompre qualsevol estructura del sistema.
4. Sense gestió de fitxers: meteo-api hauria de saber en quins sectors físics són les dades del 31 d'agost i mantenir aquesta comptabilitat pel seu compte. Canviar de disc obligaria a reescriure l'aplicació. I sense comprovació de permisos, qualsevol procés podria llegir qualsevol dada de la màquina.
5. Sense gestió de memòria i memòria cau: cada lectura aniria al disc, amb un cost 600 vegades més gran. A més, sense espais d'adreces separats, un punter erroni a agregador podria sobreescriure la memòria de meteo-api, amb corrupció silenciosa de dades servides a clients.
6. Sense apropiació en la planificació: meteo-api conservaria la CPU durant tot el seu càlcul i, si entrés en un bucle infinit per una petició mal formada, la màquina sencera quedaria inservible fins a un reinici físic.
7. Sense memòries intermèdies de xarxa al nucli: l'aplicació hauria d'esperar que cada byte es transmetés físicament abans de continuar, cosa que multiplicaria per diversos ordres de magnitud el temps de resposta i reduiria el rendiment a una fracció de l'actual.
8. Sense sistema de fitxers ni control d'accés per al registre: no hi hauria manera fiable de deixar constància del que ha passat, ni de garantir que un atacant no pugui esborrar les seves petjades. Sense registres, la resposta a incidents és impossible; hi tornarem a Auditoria, Registres i Resposta a Incidents.

Les funcions principals d'un sistema operatiu —processos i CPU, memòria, emmagatzematge i fitxers, dispositius i E/S, xarxa, protecció i seguretat, i interfície d'usuari— són el mapa de la resta d'aquest curs. Cadascuna resol un problema concret: repartir el processador, donar a cada procés un espai propi, convertir blocs en fitxers, esmorteir la lentitud del maquinari, multiplexar la xarxa, aïllar els uns dels altres i permetre que un humà doni ordres.

El que has vist en seguir una petició HTTP de cap a cap és que aquestes funcions no operen per separat. En els pocs mil·lisegons que triga meteo-api a respondre, hi intervenen totes, es donen suport les unes a les altres i, de les vuit etapes del recorregut, set són sistema operatiu i només una és codi de Meteora. Aquesta proporció explica per què val la pena entendre el que hi ha a sota.

Fins aquí hem mirat el sistema des de fora: què fa i per a qui. A la lliçó següent, Arquitectura del Nucli: Monolític, Microkernel i Híbrid, obrirem el nucli per veure com s'organitza per dins tot aquest codi, i descobriràs que hi ha maneres radicalment diferents d'estructurar-lo, amb conseqüències directes sobre el rendiment i la robustesa de meteo-01.