Tanquem el mòdul 3 amb una constatació incòmoda: portàvem tres mòduls escrivint /var/lib/meteora/lectures/2026-08-31.dat com si aquella cadena de text fos una cosa evident, quan al mòdul 2 vam deixar l'emmagatzematge en un punt molt diferent. Allà, un SSD NVMe era un vector de blocs numerats de 0 a N, adreçables per LBA, sense noms, sense carpetes, sense mides i sense propietaris. Un array gegantí de 512 o 4.096 bytes per casella. Res més.

Entre aquell vector de blocs i el camí /var/lib/meteora/lectures/2026-08-31.dat hi ha una de les abstraccions més ben resoltes de la informàtica: el sistema de fitxers. És la peça que converteix «el bloc 8.394.271» en «el fitxer de lectures d'ahir», que recorda qui el va crear i quan, que sap que ocupa 17 MB repartits en milers de blocs dispersos, i que aconsegueix que un programa en C el pugui llegir sense saber absolutament res d'LBA, sectors ni geometria.

Aquesta lliçó construeix aquesta abstracció des de baix. Definirem amb precisió què és un fitxer, veurem quines metadades porta i on viuen, disseccionarem l'inode —l'estructura central de tot sistema UNIX—, recorrerem la disposició física d'un sistema de fitxers sobre el dispositiu, calcularem per què la mida de bloc és un compromís i no una casualitat, i acabarem comparant les famílies de sistemes de fitxers que existeixen per decidir, amb arguments, quina es mereix /var/lib/meteora.

1. Del bloc cru al fitxer: quin problema resol l'abstracció
2. Què és un fitxer: contingut, metadades i nom
3. Els set tipus de fitxer d'UNIX
4. ls -l i stat interpretats camp a camp
5. L'inode: què conté i què no conté
6. Números d'inode, ls -i i l'esgotament amb df -i
7. Disposició física d'un sistema de fitxers al dispositiu
8. La mida de bloc i el seu compromís, calculat
9. Marques de temps: atime, mtime, ctime, crtime i el perquè de noatime
10. Famílies de sistemes de fitxers comparades
11. La decisió de Meteora per a /var/lib/meteora

Imagina't per un moment que Meteora no tingués sistema de fitxers i treballés directament sobre /dev/nvme0n1, el dispositiu de blocs del mòdul 2. L'ingestor hauria de resoldre, ell tot sol, aquesta llista de problemes:

Cada programa del servidor hauria de resoldre els set, cadascun a la seva manera, i cap no podria cooperar amb els altres. És exactament la situació que vam descriure a 01-01 quan parlàvem del sistema operatiu com a màquina estesa: sense ell, cada aplicació reimplementa el maquinari.

El sistema de fitxers resol els set de cop amb una sola idea:

Un fitxer és una seqüència de bytes amb nom, mida i propietari, que el sistema emmagatzema on vol i el programa llegeix com si fos contínua.

Les quatre paraules clau d'aquesta definició mereixen atenció:

• Seqüència de bytes. A UNIX un fitxer no té cap estructura interna coneguda pel sistema. No hi ha «registres», ni «camps», ni tipus. Que 2026-08-31.dat contingui 720.000 estructures Lectura de 24 bytes és un acord entre els programes de Meteora, invisible per al nucli. Altres sistemes històrics (els d'IBM, VMS) sí que imposaven estructura de registres, i la indústria va acabar donant la raó al model pla d'UNIX per la seva simplicitat.
• Amb nom. El nom és l'ansa per la qual l'usuari agafa el fitxer. Veurem a l'apartat 5 la sorpresa: el nom no és dins del fitxer.
• On vol. El sistema decideix quins blocs fa servir. Això és el que estudiarem a Assignació d'Espai, Journaling i Integritat.
• Com si fos contínua. Aquesta és la màgia. 2026-08-31.dat ocupa 4.219 blocs que poden estar escampats per tot l'SSD, i tanmateix read() els lliura en ordre com un doll de bytes. És la mateixa mena d'il·lusió que la memòria virtual del mòdul 2: adreces lògiques contigües sobre emmagatzematge físic dispers.

De fet, el paral·lelisme amb la memòria virtual és tan exacte que convé fixar-lo, perquè t'estalviarà esforç en tot el mòdul:

És la mateixa idea aplicada dues vegades: una taula de traducció que converteix un espai lògic ordenat en un espai físic desordenat.

Un fitxer té tres parts, i viuen en tres llocs diferents. Aquesta separació és la clau de tota la resta:

• El contingut: els bytes en si, a la zona de dades del dispositiu.
• Les metadades: tot el que el sistema sap sobre el fitxer. Viuen a l'inode.
• El nom: viu al directori que el conté, no al fitxer. Ho desenvoluparem a Estructures de Directoris, però ho has de saber ja per entendre l'inode.

Les metadades típiques d'un fitxer, amb el que significa cadascuna:

Fixa't en una cosa que ja s'intueix: el nom no apareix en aquesta llista. No és un oblit; és la decisió de disseny central d'UNIX, i d'ella surten els enllaços durs, l'esborrat diferit i mitja dotzena de comportaments que sorprenen fins que entens això.

A UNIX, la frase «tot és un fitxer» es pren seriosament. La mateixa interfície —open, read, write, close— serveix per a un fitxer de dades, un teclat, una canonada o una connexió de xarxa. El que canvia és el tipus, un camp de 4 bits a l'inode:

Els tres últims són vells coneguts del mòdul 3: la FIFO de /run/meteora/lectures.fifo la vam fer servir a Comunicació entre Processos, i els sòcols de domini UNIX també. La diferència és que allà els vam veure com a mecanismes d'IPC i aquí els veiem com a entrades del sistema de fitxers: tenen inode, permisos i nom, però el seu contingut no és al disc —una FIFO té una memòria intermèdia a la memòria del nucli, un sòcol té una cua de xarxa—. Ocupen un inode i zero blocs de dades.

El mateix passa amb els dispositius de bloc i de caràcter, que vam veure a Gestió de Dispositius: el seu inode no guarda punters a dades, guarda el parell (número major, número menor) que identifica el controlador. Un fitxer de dispositiu és, literalment, un inode amb un parell d'enters a dins.

Anem a mirar-ho de debò. Aquest és el llistat del directori de Meteora a meteo-01:

Els camps, d'esquerra a dreta:

1. Primer caràcter: el tipus de la taula anterior. -, l, d, b, c, p, s. D'un cop d'ull ja saps què és cada cosa.
2. Nou caràcters següents: els permisos, que veurem a Seguretat i Permisos de Fitxers.
3. El número després dels permisos: el comptador d'enllaços. Val 1 als fitxers normals i 2 al directori arxiu (ho explica 04-02).
4. Usuari i grup propietaris: meteora meteora.
5. Mida: 17.280.000 bytes per a les lectures. Però mira /dev/nvme0n1: on hi hauria d'haver la mida hi posa 259, 0. Són el major i el menor. Un fitxer de dispositiu no té mida perquè no té contingut; en el seu lloc ls mostra la parella que identifica el controlador. I la FIFO i el sòcol hi posen 0, per la mateixa raó.
6. Data: per defecte el mtime, no el de creació ni el d'últim accés (apartat 9).
7. Nom, amb el -> destinació a l'enllaç simbòlic.

ls -l és un resum. Per veure-ho tot es fa servir stat:

Camp a camp, amb el que cal entendre de cadascun:

• Mida: 17280000. Bytes lògics del fitxer: exactament 720.000 lectures × 24 bytes. És el número que retorna lseek(fd, 0, SEEK_END).
• Blocs: 33760. Aquí hi ha un parany clàssic: stat compta blocs de 512 bytes, sempre, independentment de la mida de bloc real del sistema de fitxers. 33.760 × 512 = 17.285.120 bytes ocupats al disc, una mica més que els 17.280.000 lògics. La diferència són 5.120 bytes: 4 KiB de l'últim bloc parcialment fet servir més les metadades de l'arbre d'extents. Que «blocs × 512» sigui menor que la mida és la firma d'un fitxer dispers (ho veurem a 04-04).
• Bloc d'E/S: 4096. La mida de bloc preferida per a les lectures; llegir en múltiples d'aquest número evita feina extra al nucli.
• Dispositiu: 9,0. Major 9, menor 0: /dev/md0, el RAID 1 que vam muntar a 02-05. Aquest parell identifica en quin sistema de fitxers viu l'inode, i la parella (dispositiu, node-i) és l'única cosa que identifica un fitxer de manera única a tota la màquina.
• Node-i: 1180934. El número d'inode. L'apartat 6 s'hi dedica.
• Enllaços: 1. Un sol nom apunta a aquest inode (04-02).
• Accés (0640). Dotze bits de mode, mostrats en octal i en simbòlic (04-06).
• Uid/Gid 990. L'usuari i el grup meteora. Ull: l'inode guarda números, no noms; la traducció a meteora la fa stat consultant /etc/passwd.
• Les quatre dates: apartat 9.

L'inode (index node) és l'estructura de dades que és el fitxer. Tota la resta són referències a ell. Viu al disc, en una zona reservada, i té una mida fixa: 256 bytes en un ext4 modern (128 als antics, configurable en formatar).

El seu contingut, agrupat:

I ara l'important, que és el que no hi ha:

El nom del fitxer no és a l'inode. Tampoc no hi és el camí, ni el directori al qual pertany, ni res que el relacioni amb /var/lib/meteora/lectures/2026-08-31.dat.

L'inode 1180934 no sap com es diu. Sap que és un fitxer regular de 17.280.000 bytes que pertany a l'UID 990, que hi ha 1 nom en algun lloc que hi apunta, i en quins blocs són les seves dades. Res més.

Això no és una limitació: és la decisió de disseny de la qual penja mig mòdul. Les seves conseqüències, que anirem desplegant:

Guarda't aquesta frase: l'inode és el fitxer; el nom és només una etiqueta enganxada des de fora.

Cada inode té un número únic dins del seu sistema de fitxers. Es veu amb ls -i:

Dos fitxers del mateix sistema de fitxers amb el mateix número d'inode són el mateix fitxer. Dos fitxers de sistemes de fitxers diferents poden compartir número sense tenir res a veure: per això la identitat real és el parell (dispositiu, inode), st_dev + st_ino a stat. És exactament el que comprova find -samefile i el que fa servir rsync per no copiar dues vegades el mateix contingut enllaçat.

Ara la part pràctica. A ext4, el nombre d'inodes es fixa en formatar i no es pot augmentar després. Es reserven per endavant, amb una relació per defecte d'un inode per cada 16 KiB de capacitat:

Interpretació: el volum té 13.107.200 inodes (200 GiB ÷ 16 KiB) i només en fa servir 1.834, perquè Meteora guarda un fitxer gran per dia i porta uns cinc anys funcionant. Amb aquesta política, en 100 anys faria servir 36.500 inodes: el 0,28 %.

A l'inrevés, però, es produeix la fallada més desconcertant de l'administració de sistemes:

«No queda espai al dispositiu» amb 36 GB lliures. L'error és ENOSPC i és literal des del punt de vista del nucli: no queda espai d'inodes. Un procés que crea milions de fitxers minúsculs —memòries cau, sessions, cues de correu— esgota la reserva d'inodes molt abans que els blocs. Regla de diagnòstic: davant d'un ENOSPC, executa sempre df -h i df -i; si el primer no explica res, el segon ho farà.

Per localitzar el culpable:

L'ordre compta fitxers per directori: -xdev evita saltar a altres sistemes de fitxers, -printf '%h\n' imprimeix el directori de cada fitxer, i sort | uniq -c | sort -rn agrupa i ordena. Gairebé tres milions de fitxers a sessions: aquí hi ha el problema.

La solució no és engrandir el disc, perquè els inodes no creixen: cal esborrar fitxers o reformatar amb mkfs.ext4 -i 4096 (un inode cada 4 KiB, quatre vegades més) o -N 8000000 (nombre explícit). Aquest és un dels arguments a favor d'XFS i Btrfs, que assignen inodes dinàmicament i no pateixen aquest problema.

Ja sabem què és un inode. On és físicament? Anem a obrir el dispositiu per dins. La jerarquia d'unitats, de menor a major:

El sector és la unitat mínima que el dispositiu sap llegir o escriure; ho vam veure a 02-05. El bloc lògic és la unitat mínima que el sistema de fitxers sap assignar: encara que el disc pugui llegir 512 bytes, ext4 mai no assigna menys d'un bloc a un fitxer.

Un ext4 es divideix en grups de blocs de 128 MiB, cadascun amb la seva pròpia comptabilitat. La raó és de rendiment i ve directament del mòdul 2: mantenir juntes les metadades i les dades que es fan servir juntes redueix els desplaçaments del capçal en un HDD i millora la localitat en un SSD.

Peça per peça:

El superbloc. És la fitxa d'identitat del sistema de fitxers, i ocupa un sol bloc. Conté el nombre total d'inodes i de blocs, quants en queden lliures, la mida de bloc, la mida de l'inode, el nombre de blocs per grup, l'UUID, l'etiqueta, la data de l'últim muntatge, el comptador de muntatges i l'estat (net o brut, que serà decisiu a 04-05). Sense superbloc no es pot muntar res, perquè no se sap ni on comencen els inodes. Per això ext4 en guarda còpies de seguretat en diversos grups:

Si el primari es corromp, es recupera amb sudo e2fsck -b 32768 /dev/md0, que li diu a e2fsck que faci servir la còpia del bloc 32768. És una ordre que convé tenir anotada: salva volums que semblaven perduts.

Els descriptors de grup. Un array amb una entrada per grup, que diu on són els mapes de bits i la taula d'inodes d'aquell grup i quants elements lliures té. És l'índex que permet trobar tota la resta.

El mapa de bits de blocs. Un bit per bloc del grup: 1 = ocupat, 0 = lliure. Amb blocs de 4 KiB, un grup de 128 MiB té 32.768 blocs, que són 32.768 bits = 4.096 bytes: exactament un bloc. No és casualitat; la mida del grup es tria precisament perquè el seu mapa de bits càpiga en un bloc.

El mapa de bits d'inodes. El mateix per als inodes del grup.

La taula d'inodes. L'array d'inodes pròpiament dit. Si un grup té 8.192 inodes de 256 bytes, ocupa 2 MiB = 512 blocs. Aquí és on es calcula la posició d'un inode a partir del seu número, amb aritmètica pura i sense buscar en cap índex:

Dues divisions i una multiplicació: això és tot el que costa passar d'un número d'inode a la seva posició al disc. Els inodes es numeren des de l'1, d'aquí el - 1. Aquesta és la raó profunda que l'inode sigui un número i no un nom: buscar un nom exigiria recórrer una taula; un número es resol amb aritmètica en nanosegons.

La zona de dades. Tota la resta: els blocs on són els bytes dels fitxers.

Ho pots veure a la teva màquina amb dumpe2fs:

Cada línia és un camp del superbloc real. Block count: 52428800 × 4.096 = 200 GiB. Filesystem state: clean significa que es va desmuntar correctament. I dir_index i extent són característiques que apareixeran a 04-02 i 04-05.

La mida de bloc es tria en formatar i no es pot canviar després. És un compromís genuí, i es veu amb números.

El cost d'un bloc gran: fragmentació interna. Com que l'assignació és per blocs sencers, l'últim bloc de cada fitxer queda parcialment buit, i aquell espai es perd. De mitjana es malbarata mig bloc per fitxer.

El cost d'un bloc petit: més blocs per gestionar. Més entrades a les metadades, més feina d'assignació, i peticions d'E/S més petites.

Amb els fitxers reals de Meteora (17.280.000 bytes):

Per a fitxers de 17 MB el malbaratament és irrellevant en tots els casos: 21 KB sobre 17 MB és el 0,12 %. Però el nombre de blocs a gestionar canvia per un factor de 64.

Ara l'escenari contrari, un directori amb un milió de fitxers de 800 bytes (sessions, no lectures):

Amb blocs de 64 KiB, un milió de fitxers de 800 bytes ocuparia 64 GB per emmagatzemar 800 MB. La mateixa mida de bloc que era irrellevant per a les lectures és catastròfica aquí.

Per què 4 KiB és l'estàndard universal, i no és una convenció arbitrària:

1. Coincideix amb la mida de pàgina (mòdul 2). La memòria cau de pàgines del nucli treballa en pàgines de 4 KiB; si el bloc fes el mateix, un bloc = una pàgina i no cal trossejar ni ajuntar res. Un bloc més gran que la pàgina no es pot mapar amb mmap() de manera directa, que és precisament el que fa l'agregador amb 2026-08-31.dat (02-04). De fet, Linux no admet blocs més grans que la mida de pàgina, així que a x86-64 el màxim és 4 KiB.
2. Coincideix amb el sector físic dels discos moderns (Advanced Format, 4Kn), així que cap escriptura no provoca el cicle llegir-modificar-escriure.
3. Equilibra el malbaratament per a la distribució real de mides de fitxers en un sistema típic.

Regla pràctica: fes servir 4 KiB llevat que tinguis una raó mesurada per no fer-ho. La raó per baixar a 1 KiB és un volum dedicat a milions de fitxers minúsculs; per pujar hauries d'anar a XFS en arquitectures amb pàgines més grans, o a sistemes de fitxers amb bigalloc.

Quatre dates, i tres d'elles es confonen constantment:

L'error més freqüent és creure que ctime és creation time. No ho és: és change time, el moment en què va canviar qualsevol metadada. Canviar els permisos amb chmod, el propietari amb chown o crear un enllaç dur modifica el ctime però no el mtime, perquè el contingut no ha canviat. I com que no es pot alterar cap enrere (ni tan sols touch -d el toca), el ctime és la marca que consulta un analista forense: qui manipula un fitxer pot falsejar atime i mtime, però en fer-ho actualitza el ctime, i es delata. Hi tornarem al mòdul 5.

Una taula de què toca cada operació sobre 2026-08-31.dat:

¹ Reanomenar canvia el directori, no l'inode del fitxer. ² Canvia el comptador d'enllaços, que és a l'inode.

Aquí hi ha el problema pràctic. Actualitzar l'atime significa escriure al disc en llegir un fitxer. Sona absurd, i ho és: converteix una operació de només lectura en una de lectura i escriptura.

Els números per a Meteora. meteo-api serveix unes 2.000 consultes per hora, cadascuna llegint el fitxer del dia. Amb atime estricte, això són 2.000 escriptures per hora sobre l'inode d'un fitxer que ningú no ha modificat: 48.000 escriptures diàries de metadades, més la seva entrada corresponent al diari (04-05), sobre un RAID 1 on cada escriptura va als dos discos. I sobre un SSD, cicles d'escriptura gastats per res.

Les opcions de muntatge disponibles, que aplicarem a Particions, Muntatge i Sistema de Fitxers Virtual:

relatime és el compromís que va adoptar Linux: manté la semàntica que necessiten les eines que pregunten «s'ha llegit això des de l'última modificació?» (els clients de correu, sobretot) amb una fracció del cost. noatime l'elimina del tot.

Meteora munta /var/lib/meteora amb noatime, perquè cap programa del sistema no consulta l'atime de les lectures i l'estalvi és real. La regla general: en un volum de dades de servidor, noatime és gairebé sempre correcte; en un volum d'usuaris amb clients de correu antics, queda't a relatime.

N'hi ha desenes. Aquests són els que et trobaràs, amb el que de debò els distingeix:

Quatre observacions que valen més que la taula sencera:

FAT32 i el límit de 4 GiB. És el límit real que més gent es troba a la vida: copiar un vídeo de 5 GB a un llapis de memòria falla, i no per falta d'espai. FAT32 guarda la mida en 32 bits, així que 2³² − 1 = 4.294.967.295 bytes és el sostre absolut. I no té diari: un tall de llum a mitja escriptura el pot deixar incoherent sense manera automàtica de reparar-lo. Sobreviu perquè ho llegeix absolutament tot, inclosa la UEFI de la teva placa, que exigeix una partició FAT32 per arrencar.

tmpfs no és un disc. Viu a la memòria cau de pàgines i al swap: rapidíssim i volàtil. És el que hi ha darrere de /dev/shm/meteora-cache (03-03) i de /run/meteora/. Que la memòria cau de Meteora «sigui un fitxer» i alhora sigui a la RAM no és una contradicció: és un fitxer d'un sistema de fitxers que no té dispositiu al darrere. Ho veurem amb detall a 04-03.

Còpia en escriure enfront de diari. Són dues filosofies diferents per al mateix problema —sobreviure a un tall de llum—. El diari anota el que farà abans de fer-ho; la còpia en escriure mai no sobreescriu un bloc viu, escriu una còpia nova i canvia el punter al final. És el tema d'Assignació d'Espai, Journaling i Integritat.

Sumes de verificació de dades. Només Btrfs i ZFS verifiquen que les dades que retornen són les que es van escriure. ext4 i XFS verifiquen les seves metadades i el seu diari, però si un bit de les teves lectures es corromp al plat, te'l lliuren corrupte sense avisar. És la corrupció silenciosa, i també és de 04-05.

Amb tot l'anterior, ja es pot argumentar l'elecció en lloc de copiar-la d'un tutorial. El perfil de càrrega de Meteora:

Els candidats i el seu descart raonat:

Decisió: ext4, amb aquesta justificació:

1. Maduresa i previsibilitat. És el sistema de fitxers amb més hores de vol de l'ecosistema Linux. Per a dades irrecuperables, «avorrit i provat» val més que «modern i prometedor».
2. Extents. Un fitxer de 17 MB contigu es descriu amb un sol extent en lloc de 4.219 punters. Ho mesurarem amb filefrag a 04-05.
3. Eines. dumpe2fs, debugfs, tune2fs, e2fsck i resize2fs (que sí que redueix, a diferència d'XFS) formen el joc més complet. Quan alguna cosa va malament a les tres de la matinada, això pesa.
4. El diari en mode ordered garanteix que mai no apareixeran dades d'un altre fitxer dins de les lectures després d'una fallada. Ho justificarem a 04-05.
5. Els inodes no són cap problema en aquesta càrrega: 1.834 de fets servir de 13 milions.
6. La manca de sumes de verificació de dades es compensa per una altra via: md verifica el RAID 1 amb un scrub setmanal, i l'ingestor guarda un CRC32 per lectura en el seu propi format.

Els paràmetres exactes del formatatge:

Què fa cada opció i per què aquí:

• -b 4096: coincideix amb la pàgina i amb el sector físic de l'NVMe; a més permet mmap() directe.
• -i 1048576: per defecte hi hauria 13 milions d'inodes, dels quals se'n fan servir 1.834; amb un inode per MiB en queden 200.000, de sobres, i s'estalvien uns 3 GiB de taula d'inodes que passen a ser espai útil. És un ajust segur només perquè coneixem la càrrega.
• -m 1: ext4 reserva el 5 % per a root, perquè un disc ple no impedeixi iniciar sessió ni operar. En un volum de dades de 200 GiB això són 10 GiB immobilitzats; amb l'1 % són 2 GiB, marge suficient. Ull: a / mai no baixis del 5 %.
• -O extent: extents en lloc de punters indirectes (04-05).
• -O dir_index: índexs hash per a directoris grans (04-02).
• -O metadata_csum: sumes de verificació de metadades, que detecten corrupció de l'inode o del mapa de bits.

I així és com /var/lib/meteora/lectures/2026-08-31.dat deixa de ser una cadena màgica i passa a ser l'inode 1180934 de l'ext4 etiquetat meteora-dades sobre /dev/md0.

Creure que el ctime és la data de creació. És change time: canvia amb chmod, chown o en crear un enllaç dur. La creació real és el crtime, que només mostra stat en sistemes moderns. Confondre'ls porta a conclusions falses en qualsevol anàlisi forense.

Interpretar malament el camp Blocs de stat. Sempre són blocs de 512 bytes, encara que el sistema faci servir 4 KiB. Si multipliques per 4.096 obtindràs una mida vuit vegades més gran que la real.

No mirar df -i davant d'un ENOSPC. Un disc al 26 % que dona «No queda espai al dispositiu» és gairebé sempre esgotament d'inodes. Comprova sempre les dues coses.

Suposar que el nombre d'inodes es pot ampliar. A ext4 es fixa en formatar i no hi ha marxa enrere. Si preveus milions de fitxers petits, decideix -i abans, o fes servir XFS o Btrfs, que els assignen dinàmicament.

Triar un bloc gran «perquè és més ràpid». Amb un milió de fitxers de 800 bytes, un bloc de 64 KiB malbarata el 99 % de l'espai. La mida de bloc depèn de la distribució de mides dels teus fitxers, no d'una intuïció sobre velocitat. I a Linux no pot superar els 4 KiB de la pàgina.

Formatar amb mkfs la partició equivocada. mkfs no pregunta. Confirma sempre amb lsblk i blkid abans de prémer Retorn; ho veurem a 04-03.

Consell: guarda la sortida de dumpe2fs -h dels teus volums. Tenir a mà l'UUID, la mida de bloc i les posicions dels superblocs de còpia converteix una recuperació d'emergència en un tràmit de dos minuts.

Consell: fes servir stat en lloc d'ls -l quan alguna cosa no quadri. Mostra les quatre dates, l'inode, el dispositiu i els blocs reals. La meitat dels misteris amb fitxers es resolen llegint un stat amb calma.

Consell: comprova el tipus abans de donar res per fet. Abans de fer cat sobre alguna cosa desconeguda, mira el primer caràcter d'ls -l. Un cat sobre un dispositiu de bloc de 200 GiB, o sobre una FIFO sense escriptor, no acaba com esperes.

Sense fer servir ls -l, escriu una ordre que classifiqui tot el que hi ha a /dev, /run i el teu directori personal per tipus de fitxer, comptant quants n'hi ha de cadascun. Després agafa un fitxer regular d'almenys 10 MB, executa-hi stat, i respon: (a) quants blocs de 4 KiB ocupa realment?, (b) quant espai es malbarata a l'últim bloc?, (c) coincideixen mtime i ctime, i què significa que coincideixin o que no?

Un volum de 500 GiB allotjarà dues càrregues possibles. Càrrega A: els fitxers diaris de Meteora, 17.280.000 bytes cadascun, durant 30 anys. Càrrega B: 20 milions de fitxers de sessió de 600 bytes. Per a mides de bloc d'1, 4 i 64 KiB, calcula en cada càrrega: blocs totals necessaris, espai realment ocupat, malbaratament absolut i percentatge. Després indica quina mida triaries per a cada càrrega i si un sol volum pot servir per a les dues.

Un company t'avisa: el servei de sessions de meteo-01 falla amb «No queda espai al dispositiu», però df -h mostra el volum al 31 %. Escriu el procediment complet de diagnòstic —quines ordres executes, en quin ordre i què esperes veure a cadascuna—, l'explicació tècnica de per què passa, la solució immediata per restaurar el servei i la solució definitiva perquè no torni a passar. Inclou l'ordre de formatatge que faries servir i justifica'n els paràmetres.

Solució 1

Classificar per tipus es fa amb find -type o, millor, amb el format de stat:

-printf '%y' imprimeix una sola lletra amb el tipus (f regular, d directori, l enllaç, b, c, p, s), i sort | uniq -c els compta. Sortida típica:

Per a les preguntes, amb un stat que dona Mida: 17280000 i Blocs: 33760:

(a) stat compta blocs de 512 B: 33.760 × 512 = 17.285.120 bytes. En blocs de 4 KiB són 17.285.120 / 4.096 = 4.220 blocs. Les dades necessiten ⌈17.280.000 / 4.096⌉ = 4.219, així que el bloc extra són metadades de l'arbre d'extents.

(b) 17.280.000 = 4.218 blocs complets + 3.072 bytes. L'últim bloc fa servir 3.072 de 4.096, així que es malbaraten 1.024 bytes: el 0,006 % del fitxer. Irrellevant aquí, decisiu amb fitxers de 800 bytes.

(c) Si mtime i ctime coincideixen, l'última operació va ser una escriptura de contingut (que actualitza tots dos). Si el ctime és posterior, després d'escriure es va modificar alguna metadada: un chmod, un chown o un ln. Un ctime posterior al mtime sense motiu conegut és exactament el que fa sospitar un analista.

Solució 2

Càrrega A — un fitxer de 17.280.000 B, 30 anys × 365 = 10.950 fitxers:

Sobre 189 GB de dades, fins i tot 235 MB és el 0,12 %. Amb 4 KiB, el malbaratament és del 0,006 %: menyspreable. Aquí mana el nombre de blocs a gestionar, i 4.219 es maneja molt millor que 16.875.

Càrrega B — 20.000.000 de fitxers de 600 B (12 GB de dades reals):

Amb 64 KiB no hi cap: caldrien 1,3 TB en un volum de 500 GiB per guardar 12 GB de dades.

Elecció. Càrrega A: 4 KiB, per afinitat amb la pàgina i mmap(), amb malbaratament nul a la pràctica. Càrrega B: 1 KiB, que estalvia 61 GB respecte als 4 KiB. I un advertiment important per a la càrrega B: 20 milions de fitxers necessiten 20 milions d'inodes, i el mkfs per defecte en donaria 32,7 milions —just—, així que cal fixar -i 2048 o fer servir XFS.

Un sol volum per a les dues? Tècnicament sí, però és mala idea: els requisits són oposats (bloc gran i pocs inodes enfront de bloc petit i molts inodes), i a més barrejar càrregues fa que els milions de fitxers petits fragmentin l'espai que necessiten els grans. Dos volums separats, que és justament l'argument del particionament que veurem a 04-03.

Solució 3

Procediment de diagnòstic, en ordre:

El pas 2 és el diagnòstic i el 4 identifica el culpable. -xdev és important: sense això, find creuaria a altres sistemes de fitxers i comptaria fitxers que no ocupen inodes d'aquest volum.

Explicació tècnica. A ext4 el nombre d'inodes és fix i es decideix en formatar, amb un inode per cada 16 KiB per defecte. Un volum de 50 GiB té així 3.276.800 inodes. Cada fitxer, per petit que sigui, en consumeix un. Quan s'esgoten, creat() i open(O_CREAT) retornen ENOSPC —«No space left on device»— encara que quedin blocs lliures, perquè el nucli no distingeix entre els dos recursos al codi d'error. Els fitxers de sessió de 600 bytes ocupen un bloc de 4 KiB i un inode cadascun: els inodes s'esgoten quan en portes 3,2 milions, amb només 13 GB fets servir.

Solució immediata (restaurar el servei):

Esborrar els fitxers de més de 7 dies allibera inodes immediatament. Amb milions de fitxers convé find ... -delete en lloc de rm -rf, que pot desbordar la línia d'ordres.

Solució definitiva, en tres capes:

1. Purga automàtica: una unitat systemd amb temporitzador (mòdul 7) o una entrada de tmpfiles.d que esborri les sessions caducades cada hora.
2. Reformatar amb la densitat correcta, amb una còpia de seguretat prèvia:

-b 1024 perquè els fitxers són de 600 bytes i amb 4 KiB es malbarata el 85 %; -i 2048 dona un inode per cada 2 KiB, és a dir 26 milions d'inodes, molt per sobre dels 3,2 originals; -m 0 perquè és un volum de dades temporals on no cal reserva per a root.

3. Vigilància: alertar quan df -i superi el 80 %, exactament igual que es vigila l'espai. Gairebé cap sistema de monitoratge no ho fa per defecte, i per això aquesta fallada continua apareixent.

Alternativa raonable: muntar /var/spool/cache com a tmpfs, ja que les sessions són volàtils per naturalesa. S'acaben els dos problemes de cop, a canvi de RAM i de perdre-les en reiniciar (04-03).

Un fitxer és una seqüència de bytes amb nom, mida i propietari que el sistema col·loca on vol i el programa llegeix com si fos contínua. Aquesta abstracció resol de cop els set problemes que tindria qualsevol aplicació treballant sobre el vector de blocs cru del mòdul 2, i ho fa amb la mateixa estratègia que la memòria virtual: una taula de traducció que converteix un espai lògic ordenat en un espai físic dispers.

El fitxer té tres parts en tres llocs: el contingut a la zona de dades, les metadades a l'inode, i el nom al directori. La conseqüència central, de la qual penja mig mòdul, és que el nom no és dins del fitxer: l'inode 1180934 no sap que es diu 2026-08-31.dat.

A UNIX hi ha set tipus de fitxer —regular, directori, enllaç simbòlic, dispositiu de bloc, dispositiu de caràcter, FIFO i sòcol— i els quatre últims ocupen inode però zero blocs de dades: la FIFO /run/meteora/lectures.fifo i el sòcol api.sock del mòdul 3 són entrades del sistema de fitxers el contingut de les quals viu al nucli. ls -l els distingeix pel seu primer caràcter i stat ho compta tot: mida lògica, blocs de 512 bytes, dispositiu, inode, comptador d'enllaços i les quatre dates.

Físicament, un ext4 es divideix en grups de blocs de 128 MiB, cadascun amb mapa de bits de blocs, mapa de bits d'inodes, taula d'inodes i zona de dades, precedits pel superbloc —la fitxa d'identitat, amb còpies de seguretat que salven volums— i els descriptors de grup. Passar del número d'inode a la seva posició al disc costa dues divisions i una multiplicació, i aquesta és la raó profunda que l'inode sigui un número.

La mida de bloc és un compromís mesurable: 4 KiB és l'estàndard perquè coincideix amb la pàgina de memòria (i per tant amb la memòria cau de pàgines i amb mmap()) i amb el sector físic modern; abaixar-la té sentit amb milions de fitxers minúsculs i apujar-la, a Linux, ni tan sols és possible. Els inodes, a ext4, es fixen en formatar: d'aquí l'ENOSPC amb el disc mig buit que només df -i explica. I les quatre marques de temps distingeixen llegir (atime), modificar contingut (mtime), modificar metadades (ctime) i crear (crtime); noatime elimina 48.000 escriptures diàries inútils a meteo-01.

Amb la comparació de famílies a la mà, Meteora tria ext4 per a /var/lib/meteora: maduresa davant de dades irrecuperables, extents per descriure 17 MB en un sol tram, el joc d'eines més complet per a les tres de la matinada, i un ajust conscient de -i 1048576 i -m 1 que recupera uns 11 GiB per a dades útils.

Ens queda el cap solt que hem anat deixant a cada apartat: el nom. Sabem que no és a l'inode, sabem que viu «al directori», i hem dit que un directori és «un fitxer especial», però no n'hem obert cap. Què hi ha exactament dins de /var/lib/meteora/lectures/? Com aconsegueix el sistema convertir la cadena /var/lib/meteora/lectures/2026-08-31.dat en el número 1180934, i quants accessos a disc li costa? Per què un enllaç simbòlic pot quedar-se trencat i un de dur no? I què passa quan un directori té cent mil fitxers a dins?

Tot això és el que obre la lliçó següent: Estructures de Directoris.