Vam acabar la lliçó anterior assenyalant una costura que portem ignorant tot el mòdul. Quan recorrem /var/lib/meteora/lectures/2026-08-31.dat component a component, donem per fet que l'arbre és una cosa homogènia. No ho és. / és un ext4 sobre una partició del primer NVMe; /var/lib/meteora és un altre ext4, sobre el RAID 1 /dev/md0; /run és tmpfs i viu a la RAM; /proc no té cap dispositiu al darrere i els seus fitxers s'inventen en el moment de llegir-los. Quatre sistemes de fitxers radicalment diferents, amb estructures internes incompatibles, i tanmateix la resolució de camins camina d'un a l'altre sense assabentar-se'n.

Aquesta lliçó explica com s'aconsegueix això, i ho fa en dues meitats que es complementen. La primera és d'administració: com es trosseja un dispositiu de blocs en particions, com LVM hi afegeix una capa de flexibilitat a sobre, com es crea un sistema de fitxers i —l'operació central— què passa exactament en executar mount, amb /etc/fstab camp a camp i les opcions que protegeixen de debò. La segona és d'arquitectura: el Sistema de Fitxers Virtual (VFS), la capa d'indirecció del nucli que fa que el mateix open() funcioni sobre un SSD, sobre la RAM i sobre un servidor a l'altra banda de la xarxa.

En acabar sabràs particionar i muntar un servidor amb criteri, entendre per què separar /var de / no és una mania sinó prevenció, resoldre el «target is busy» que tothom pateix, i explicar amb precisió per què /proc/cpuinfo es comporta com un fitxer sense ser-ho.

1. Del dispositiu de blocs a la partició: MBR i GPT
2. Esquema de particionament d'un servidor i per què separar /var
3. Veure què hi ha: lsblk, fdisk -l i blkid
4. LVM: volums físics, grups de volums i volums lògics
5. Instantànies d'LVM per copiar /var/lib/meteora en calent
6. Crear el sistema de fitxers amb mkfs
7. El muntatge: què passa exactament en executar mount
8. Identificació estable: UUID, etiquetes i /etc/fstab camp a camp
9. Opcions de muntatge i què protegeix cadascuna
10. Desmuntar, «target is busy» i com resoldre-ho
11. Muntatges bind i espais de noms de muntatge
12. El Sistema de Fitxers Virtual (VFS) i els seus quatre objectes
13. Sistemes de fitxers virtuals i en memòria
14. Sistemes de fitxers en xarxa: NFS i SMB

Al mòdul 2 vam deixar el disc com un vector de blocs adreçables per LBA. Una partició és simplement un rang contigu d'aquell vector declarat com a unitat independent: «de l'LBA 2048 al 1050623, això és una cosa». Res més. La partició no imposa format ni contingut; només delimita.

Per què particionar en lloc de fer servir el disc sencer? Per quatre raons que continuen sent vàlides: aïllar l'ompliment (si /var/log es desborda, no ha d'impedir que puguis iniciar sessió), aplicar polítiques diferents de muntatge a cada zona, fer servir sistemes de fitxers diferents segons la càrrega (04-01), i satisfer els requisits d'arrencada (la UEFI exigeix una partició FAT32; el xifratge de disc necessita /boot sense xifrar).

La taula de particions viu als primers sectors del disc, i n'hi ha dos formats. MBR (Master Boot Record), del 1983, ocupa els primers 512 bytes: 446 per al codi d'arrencada, 64 per a la taula —4 entrades de 16 bytes— i 2 per a la signatura 0x55AA. GPT (GUID Partition Table), part d'UEFI, fa servir una capçalera a l'LBA 1 i un array d'entrades de 128 bytes, amb una còpia completa al final del disc.

Tres diferències importen de debò. El límit de 2 TiB d'MBR és infranquejable: inici i mida es guarden en 32 bits de sectors de 512 bytes, i 2³² × 512 = 2 TiB, així que qualsevol disc de 4 o 8 TB exigeix GPT. La redundància: a MBR, corrompre 512 bytes destrueix la taula i l'accés a tot; GPT en guarda una còpia íntegra al final i verifica totes dues amb CRC32, de manera que gdisk en reconstrueix una a partir de l'altra —la diferència entre «he perdut el disc» i «he trigat un minut»—. I l'MBR protector: GPT escriu a l'LBA 0 un MBR fals amb una partició de tipus 0xEE que cobreix tot el disc, perquè una eina antiga el vegi com a ocupat i no el formati alegrement.

Regla actual: fes servir GPT sempre, llevat que necessitis arrencar una BIOS heretada molt antiga.

Aquest és l'esquema real de meteo-01, amb dos NVMe de 512 GB en RAID 1 (02-05) més el volum de dades:

I ara la justificació, que és el que importa. Separar /var de / no és un ritual heretat: prevé un mode de fallada concret i freqüent.

/var conté tot allò que creix sense control: registres, cues de correu, memòries cau, bases de dades, imatges de contenidors. Si comparteix partició amb / i un registre es desboca, cap procés no pot crear temporals, systemd no pot escriure el seu estat, sudo pot fallar en no poder registrar, l'intèrpret d'ordres no guarda historial ni fitxers de bloqueig, i —el que és greu— no pots iniciar sessió, perquè el teu perfil necessita escriure.

Aquesta última conseqüència és tot l'argument: un / ple és un servidor que no et deixa entrar a arreglar-lo. Amb /var separat, un registre desbocat omple /var, fallen els serveis d'aquella partició, i / conserva espai perquè puguis connectar-t'hi, diagnosticar i esborrar. És també la raó del -m 5 que ext4 reserva per defecte per a root (04-01) i que a / no l'hagis d'abaixar.

El mateix raonament, aplicat a la resta: /boot manté el nucli accessible encara que / estigui xifrat o danyat; /home impedeix que un usuari ompli el sistema i permet reinstal·lar sense perdre dades; /tmp muntat noexec,nosuid talla molts exploits; i /var/lib/meteora aïlla dades irrecuperables al seu propi RAID, amb el seu propi mkfs i el seu noatime.

El contraargument honest: les particions fixes malbaraten espai —/ amb 30 GiB lliures no ajuda un /var ple— i són difícils de redimensionar. Aquesta és exactament la mancança que LVM ve a resoldre.

Tres eines, tres punts de vista. No formatis ni particionis mai sense haver mirat les tres.

lsblk mostra l'arbre de dispositius de blocs: què conté què.

El que és valuós és la jerarquia: es veu que md0 està format per dues particions de discos diferents i que és ell, i no elles, qui porta l'ext4. TYPE distingeix disk, part, raid1, lvm i crypt. I un camp buit a MOUNTPOINT significa que no està muntat, que és el primer que cal comprovar abans de tocar res.

fdisk -l entra a la taula de particions:

El que aporta i lsblk no: Tipus d'etiqueta de disc: gpt (confirma el format), els LBA exactes d'inici i final, i la mida de sector lògica/física. L'inici al sector 2048 no és casual: alinea la primera partició a 1 MiB, cosa que garanteix que els blocs de 4 KiB del sistema de fitxers coincideixin amb els sectors físics del disc i amb les pàgines d'esborrat de l'SSD. Una partició mal alineada provoca cicles llegir-modificar-escriure a cada operació i pot costar el 30 % del rendiment; avui les eines alineen soles, però convé saber per què hi ha aquell 2048 allà.

blkid identifica el contingut: quin sistema de fitxers hi ha i amb quin UUID.

Aquí hi ha l'UUID que farem servir a /etc/fstab, i l'etiqueta meteora-dades que vam posar amb mkfs -L a 04-01. Ull amb la distinció: UUID identifica el sistema de fitxers (l'escriu mkfs al superbloc) i PARTUUID identifica la partició (l'escriu la taula GPT). Reformatar canvia l'UUID però no el PARTUUID.

El problema de les particions fixes és que decideixes les mides el dia de la instal·lació, quan menys en saps, i canviar-les després és arriscat. LVM (Logical Volume Manager) insereix una capa d'indirecció que ho resol, amb tres nivells:

• PV (physical volume): un dispositiu de blocs —partició, disc sencer o RAID— lliurat a LVM.
• VG (volume group): la unió de diversos PV en una reserva única d'espai, dividida en extents de 4 MiB.
• LV (logical volume): un dispositiu de blocs virtual construït amb extents del VG. A sobre s'hi fa mkfs i es munta, exactament igual que sobre una partició.

La creació completa, i després l'ampliació en calent, sense desmuntar ni aturar el servei:

Dos passos perquè són dues capes: lvextend engrandeix el dispositiu virtual i resize2fs estén l'ext4 perquè ocupi l'espai nou. L'ordre importa: en ampliar, primer el volum i després el sistema de fitxers; en reduir, a l'inrevés —primer resize2fs per encongir l'ext4 i després lvreduce—, perquè si redueixes el volum abans que el sistema de fitxers, talles dades i les perds. lvresize -r fa els dos passos en l'ordre correcte i és la manera segura de fer-ho. Una nota que connecta amb 04-01: ext4 es pot reduir; XFS no, perquè xfs_growfs només creix; és un argument fort a favor d'ext4 quan no saps com evolucionaran els teus volums.

Aquí hi ha la funcionalitat que resol un problema real de Meteora. Copiar /var/lib/meteora/lectures/2026-09-01.dat mentre l'ingestor hi escriu produeix una còpia inconsistent: el principi del fitxer és de les 03:00 i el final de les 03:04, amb una estructura Lectura possiblement tallada per la meitat. Aturar el servei mitja hora cada nit no és acceptable.

Una instantània (snapshot) d'LVM congela l'estat d'un volum en un instant:

Com funciona: la instantània no copia res en crear-se. És una taula buida més una regla de còpia en la primera escriptura (copy-on-write): quan l'ingestor escriu en un bloc del volum original, LVM primer copia el contingut antic a la zona de la instantània i després deixa escriure. Així, qui llegeix la instantània veu l'estat congelat i qui llegeix l'original veu l'actual.

I ara l'advertiment, que és la part que la gent ignora i després lamenta:

Dimensionar-la és aritmètica: si Meteora escriu 17,3 MB al dia i la còpia triga 20 minuts, canviaran uns 240 KB, així que 20 GB donen marge de sobres fins i tot per a un pic anòmal. La vigilància es fa amb lvs, mirant la columna Data%; si s'acosta al 100 %, cal ampliar-la amb lvextend ja:

Un matís d'honestedat tècnica: la instantània congela els blocs del dispositiu, no la memòria. Si l'ingestor tenia dades a la memòria cau de pàgines sense abocar, la instantània no les té. Per això la còpia perfecta porta un pas previ: demanar al servei que faci fsync() (o enviar-li SIGHUP), executar sync, i llavors crear la instantània. Ho veurem en parlar de fsync a Gestió de Fitxers, i les garanties de consistència són el tema d'Assignació d'Espai, Journaling i Integritat.

mkfs escriu sobre el dispositiu les estructures que vam estudiar a 04-01: superbloc, descriptors de grup, mapes de bits i taula d'inodes. No pregunta i no avisa: si el dispositiu és l'equivocat, les dades anteriors deixen de ser accessibles a l'instant.

Les opcions que de debò es fan servir, i què decideix cadascuna:

El procediment segur, amb el simulacre inclòs:

Les tres primeres ordres responen «és el dispositiu correcte?», «què conté ara?» i «està muntat?» en cinc segons, i eviten l'accident més car de l'administració de sistemes. El pas 4 amb -n imprimeix exactament el que faria —nombre d'inodes, de blocs, posicions dels superblocs de còpia— sense tocar res.

Arribem a l'operació central. Muntar és empeltar l'arbre d'un sistema de fitxers en un punt de l'arbre global, de manera que la resolució de camins creui d'un a l'altre sense notar-ho.

Els passos que executa el nucli, en ordre:

1. Resoldre el punt de muntatge. /var/lib/meteora es converteix en un inode, amb l'algorisme de 04-02. Ha d'existir i ser un directori; si no, ENOTDIR o ENOENT.
2. Obrir el dispositiu i llegir-ne el superbloc, que a ext4 comença al byte 1024: d'allà surten la mida de bloc, el nombre d'inodes, la posició de la taula d'inodes, l'UUID, les característiques actives i l'estat.
3. Comprovar l'estat. Si diu «brut» —no es va desmuntar bé—, es dispara la recuperació des del diari (04-05). Si exigeix característiques que aquest nucli no admet, es rebutja el muntatge.
4. Crear un objecte superblock en memòria, la representació viva del sistema de fitxers, amb les seves operacions (llegir inode, escriure inode, estadístiques...).
5. Crear una estructura vfsmount que associa aquell superblock amb l'inode del punt de muntatge.
6. Enganxar la dentry. A partir d'ara, quan la resolució de camins arribi a la dentry de /var/lib/meteora, veurà la marca d'«aquí hi ha un muntatge» i saltarà a l'inode arrel del nou sistema de fitxers.
7. Registrar-lo a la taula de muntatges, visible a /proc/mounts.

El pas 6 és la clau de tot, i explica el comportament més desconcertant del muntatge:

Muntar sobre un directori no buit no n'esborra el contingut: l'oculta. Els fitxers continuen allà, intactes, però el camí ja no hi arriba perquè el pas 6 desvia la resolució.

Es comprova fàcilment:

D'aquí un incident clàssic: algú escriu dades a /var/lib/meteora abans de muntar el volum, després munta, i aquelles dades desapareixen de la vista mentre continuen ocupant espai invisible a /. Per veure-les sense desmuntar existeix el truc del bind mount de l'apartat 11.

La taula de muntatges:

/proc/mounts és la veritat del nucli, amb les opcions realment en vigor. mount sense arguments mostra el mateix, i findmnt ho presenta en arbre: accepta un punt de muntatge o un dispositiu, filtra per tipus (-t ext4) i retorna un codi de sortida útil per a scripts, així que és l'eina que cal fer servir.

Un problema real: els noms /dev/sdX no són estables. S'assignen en l'ordre en què el nucli detecta els discos, que depèn de la velocitat d'arrencada de cada controlador, de l'ordre dels ports i de si hi ha un USB connectat; el disc que avui és /dev/sdb pot ser /dev/sdc demà, i una entrada de fstab que l'anomeni muntarà el volum equivocat o farà fallar l'arrencada. Les quatre maneres d'identificar un dispositiu:

Fes servir UUID= a /etc/fstab. És el que fan tots els instal·ladors moderns. L'única precaució: l'UUID canvia en reformatar, així que després d'un mkfs cal actualitzar fstab o el sistema no arrencarà.

L'/etc/fstab real de meteo-01:

Els sis camps, un a un:

1. Origen. Què muntar: UUID, etiqueta, dispositiu, o un nom arbitrari per als sistemes virtuals (tmpfs, proc).
2. Punt de muntatge. On. Per a swap, none.
3. Tipus. ext4, vfat, tmpfs, swap, nfs... o auto perquè mount ho dedueixi llegint el superbloc.
4. Opcions, separades per comes i sense espais. És el camp de l'apartat següent.
5. dump. Relíquia de la utilitat dump dels anys 80. Avui sempre 0.
6. pass. Ordre de comprovació amb fsck en arrencar: 1 per a l'arrel, 2 per a la resta (es comproven en paral·lel si són en discos diferents) i 0 per no comprovar —obligatori en tmpfs i sistemes de xarxa, que no tenen fsck—.

L'error més perillós de tot aquest mòdul viu a fstab: una línia mal escrita pot impedir que la màquina arrenqui, i la deixa en mode d'emergència sense accés remot. El procediment segur és innegociable:

findmnt --verify comprova que els UUID i els punts de muntatge existeixen i que les opcions són vàlides sense muntar res. mount -a intenta muntar-ho tot: si hi ha un error, apareix ara, amb la màquina viva, i no a l'arrencada. I si tot i així alguna cosa surt malament, l'opció nofail evita que la fallada d'una entrada bloquegi l'arrencada —molt recomanable en discos externs i muntatges de xarxa—.

Les opcions del quart camp són una de les eines d'enfortiment més barates que existeixen: costen zero rendiment i tanquen classes senceres d'atac.

El trio noexec,nosuid,nodev és la recepta estàndard per a qualsevol volum que contingui només dades. nosuid és el més important: sense això, un atacant amb permís d'escriptura pot col·locar-hi una còpia de /bin/bash amb el bit setuid de root i obtenir un intèrpret de superusuari; amb nosuid el nucli ignora aquell bit i l'atac no funciona —una paraula a fstab enfront d'una escalada a root—. nodev tanca la via anàloga amb dispositius: sense això es podria crear un fitxer de dispositiu amb el major/menor de /dev/sda i llegir el disc sencer saltant-se els permisos. I noexec impedeix executar binaris des d'allà, encara que no és una barrera forta: un script continua corrent amb bash script.sh i un binari amb /lib/ld-linux.so.2 ./binari, així que fes-lo servir com a capa de defensa, no com a mur.

Per això /var/lib/meteora es munta amb noatime,nosuid,nodev,noexec: conté dades, mai programes, així que les quatre opcions són gratis i tanquen tres vectors. Aplicar el mateix trio a /tmp, /var i /home és una de les millors relacions esforç/benefici de l'administració de sistemes, i hi tornarem al mòdul 5. Les opcions es poden canviar en calent amb mount -o remount,ro /var/lib/meteora (i rw per tornar), que és justament el que fa el nucli amb errors=remount-ro en detectar un error d'E/S: congelar les escriptures per no empitjorar el dany.

umount desmunta: aboca les escriptures pendents, sincronitza el superbloc, el marca com a net (decisiu per a 04-05) i desenganxa el punt de muntatge. Però:

Un sistema de fitxers està ocupat si algun procés l'està fent servir, i «fent servir» inclou quatre casos que la gent oblida:

1. Té un fitxer obert a dins (04-04).
2. Té el seu cwd a dins (04-02).
3. Té un fitxer mapat en memòria amb mmap() (02-04).
4. Hi ha un altre muntatge a sobre d'un subdirectori seu.

El diagnòstic, amb dues eines complementàries:

A lsof, la columna FD és la clau: cwd és directori de treball, mem és fitxer mapat, i un número (7r) és un descriptor obert. fuser -vm /var/lib/meteora diu el mateix amb lletres: c (cwd), e (executable en ús), f (fitxer obert), r (arrel) i m (mapat).

Les solucions, en ordre de preferència:

Sobre les tres últimes, amb honestedat. umount -l (lazy) desenganxa el punt de muntatge immediatament de la jerarquia, però manté el sistema de fitxers viu fins que es tanqui l'últim descriptor: els camins deixen de funcionar a l'instant, però el dispositiu continua en ús, així que si el teu objectiu era desconnectar-lo o formatar-lo, encara no pots. umount -f està pensat per a NFS amb el servidor caigut, on els processos estan bloquejats en estat D; en un sistema local pot deixar escriptures sense abocar. I fuser -k envia SIGKILL, sense donar oportunitat de desar res: comprova abans amb fuser -vm a qui mataràs.

Un quart cas, poc conegut però freqüent: si el sistema de fitxers sembla lliure i tot i així està ocupat, mira si tens un altre muntatge a sobre (un bind mount, un contenidor, un overlay) amb findmnt -R /var/lib/meteora, que mostra el subarbre de muntatges recursivament.

Un muntatge bind fa visible un directori ja existent en un segon punt de l'arbre. No copia res ni crea un enllaç: és el mateix sistema de fitxers muntat dues vegades.

Ara els dos camins porten als mateixos inodes. La diferència amb un enllaç simbòlic és substancial:

Aquesta última fila és la més útil a la pràctica: pots exposar un directori de dades a un servei només per llegir, sense tocar l'original, i de passada resoldre l'enigma de l'apartat 7 —veure el que va quedar ocult sota un muntatge— sense desmuntar res:

El servei que serveix /srv/publicacio/dades no pot escriure; l'ingestor, que fa servir el camí original, sí. És el mecanisme darrere de ReadOnlyPaths= de systemd (mòdul 7) i dels volums de només lectura de Docker.

Els muntatges bind són, a més, la porta d'entrada a un concepte més gran: els espais de noms de muntatge (mount namespaces). Linux permet que cada procés tingui la seva pròpia taula de muntatges, de manera que /var/lib/meteora signifiqui coses diferents per a dos processos de la mateixa màquina. És la base dels contenidors, que ho combinen amb pivot_root, sistemes de fitxers per capes (overlayfs) i cgroups; es veu complet a Contenidors: Namespaces i cgroups. Aquí n'hi ha prou de quedar-se amb què la taula de muntatges no és necessàriament global, i que /proc/<pid>/mountinfo diu quina veu cada procés.

Hem arribat a la peça que ho explica tot. Considera aquest programa:

Quatre sistemes de fitxers incompatibles: un amb inodes i extents en un SSD, un altre que viu a la memòria cau de pàgines, un altre que genera el contingut en el moment de la lectura executant codi del nucli, i un altre que tradueix cada operació en paquets de xarxa. I tanmateix, les mateixes quatre línies de codi funcionen sobre els quatre.

Això ho fa possible el VFS (Virtual File System), una capa d'abstracció dins del nucli:

La idea és exactament la del polimorfisme en programació orientada a objectes, implementada en C amb taules de punters a funció. El VFS defineix quines operacions existeixen; cada sistema de fitxers hi aporta la seva implementació. Quan arriba un read(), el VFS no sap llegir res: mira la taula d'operacions del fitxer i crida el punter corresponent, que apunta a ext4_file_read_iter, a shmem_file_read_iter o a la funció del mòdul de procfs.

Els quatre objectes del VFS, que convé tenir clars perquè expliquen comportaments concrets:

Les relacions entre ells responen preguntes que potser t'has fet. Diverses dentries poden apuntar al mateix inode: això són els enllaços durs, dos noms i un fitxer. Diversos file poden apuntar al mateix inode: dos processos que obren el mateix fitxer tenen objectes file diferents —cadascun amb el seu desplaçament i el seu mode— sobre un sol inode, i d'aquí surt tot el comportament de descriptors, fork i dup de 04-04. I l'inode del VFS no és l'inode del disc, sinó la seva representació en memòria comuna a tots els sistemes de fitxers: un fitxer de procfs té inode del VFS encara que al disc no hi existeixi res.

Un exemple de la taula d'operacions, simplificat del nucli real:

read() en mode usuari acaba, després del canvi a mode nucli de 01-06, a vfs_read(), que fa essencialment file->f_op->read_iter(...). Una indirecció per punter a funció, i aquí és on el camí es bifurca cap a ext4, tmpfs o NFS.

El que el VFS aporta, resumit: una sola implementació de les crides al sistema per a tots els sistemes de fitxers; memòries cau compartides (pàgines, dentries, inodes) que beneficien tothom; la possibilitat d'afegir un sistema de fitxers nou com a mòdul sense tocar la resta del nucli; i la transparència que permet que un camí creui d'ext4 a tmpfs a mig camí sense que cap programa se n'assabenti. És la mateixa filosofia de màquina estesa de 01-01, aplicada una capa més avall.

Amb el VFS entès, els sistemes de fitxers «rars» deixen de ser-ho. Tots implementen la mateixa interfície; el que canvia és d'on treuen les dades.

procfs és el més peculiar: els seus fitxers no existeixen. Quan executes cat /proc/2841/status, el read() arriba via VFS a una funció del nucli que recorre el task_struct del procés 2841 i formata text sobre la marxa. Per això ls -l /proc/2841/status mostra mida 0 —el nucli no sap quants bytes produirà fins a generar-los— i per això el contingut canvia entre dues lectures consecutives. Tot el que hem fet servir dels mòduls 2 i 3 —/proc/<pid>/maps, /proc/<pid>/stack, /proc/<pid>/fd, /proc/mounts— és això: una interfície de consulta al nucli disfressada de fitxers, per poder-la fer servir amb cat, grep i awk en lloc d'amb una API especial. És una de les millors idees de Linux.

tmpfs és un sistema de fitxers complet el magatzem del qual és la memòria cau de pàgines. És rapidíssim, perquè una escriptura és una còpia a la RAM; és volàtil, i això és una característica i no un defecte —és per això que /run/meteora/lectures.fifo i /run/meteora/api.sock són allà (04-02)—; creix i encongeix dinàmicament fins al límit de size=; i pot anar-se'n a swap sota pressió de memòria, a diferència d'un disc RAM clàssic que la immobilitza.

I aquí es tanca un cercle del mòdul 3. La memòria cau de Meteora, /dev/shm/meteora-cache, la vam crear amb shm_open() + mmap() com a memòria compartida POSIX. Ara ja es veu què és realment: shm_open() és un open() sobre un fitxer de tmpfs muntat a /dev/shm, i mmap() mapa les seves pàgines en diversos processos. La memòria compartida POSIX a Linux està implementada sobre el sistema de fitxers, i per això li pots fer ls -l, chmod i rm com a qualsevol altre fitxer:

128 MiB de memòria cau que són, alhora, un fitxer i un segment de memòria compartida. No hi ha contradicció: és el VFS fent la seva feina.

El VFS permet una cosa més ambiciosa: que el sistema de fitxers estigui en una altra màquina. El client implementa les operacions del VFS traduint-les a peticions de xarxa.

Muntar-los és com muntar qualsevol altra cosa, que és precisament la gràcia del VFS:

Els tres problemes que cal conèixer abans de fer-los servir en producció:

1. La latència ho canvia tot. Un stat() local costa microsegons; sobre NFS, una anada i tornada de xarxa: entre 0,1 i 5 ms. Un ls -l d'un directori amb 1.000 fitxers fa 1.000 stat(), cosa que en local són mil·lisegons i sobre NFS poden ser cinc segons. La causa no és mai l'amplada de banda, sinó el nombre d'anades i tornades.

2. La semàntica no és la mateixa. POSIX garanteix que un write() completat és visible immediatament per a qualsevol altre procés; NFS fa servir coherència feble, desa atributs i dades a la memòria cau, i un altre client pot trigar segons a veure el canvi. Pitjor encara, el bloqueig de fitxers (flock, que veurem a 04-04) és notòriament fràgil sobre NFS. Regla pràctica: no posis sobre NFS res que depengui de bloqueigs o d'escriptures coordinades entre màquines, bases de dades en particular.

3. hard enfront de soft. Amb hard (per defecte), si el servidor deixa de respondre els processos es queden bloquejats indefinidament en estat D, sense respondre ni a SIGKILL: el quadre clínic del mòdul 3 i el motiu del detector hung task de 03-06. L'alternativa soft retorna error després d'un temps límit, però pot corrompre dades si l'error arriba a mitja escriptura. L'equilibrat és hard més intr (o NFSv4, que permet interrompre), i muntar sempre amb nofail.

Meteora fa servir NFS només per a l'arxiu històric de només lectura a /mnt/historic: dades que ja no canvien, sense bloqueigs, sense escriptures concurrents. /var/lib/meteora, on l'ingestor escriu constantment, és en emmagatzematge local sobre RAID 1, i ara ja tens els tres motius tècnics pels quals aquella decisió és la correcta.

Fer servir /dev/sdX a /etc/fstab. Els noms del nucli canvien amb l'ordre de detecció. Fes servir UUID= sempre, i recorda que l'UUID canvia en reformatar.

Editar fstab sense validar. Una línia mal escrita deixa la màquina en mode d'emergència a l'arrencada següent, i si és un servidor remot, sense accés. Còpia de seguretat, findmnt --verify i mount -a abans de reiniciar. Sempre.

Escriure al punt de muntatge abans de muntar. Els fitxers queden ocults sota el muntatge, i ocupen espai invisible a la partició de sota. Comprova-ho amb un bind mount de /.

Formatar el dispositiu equivocat. mkfs no pregunta. Les tres ordres de verificació (lsblk, blkid, findmnt --source) més el simulacre amb -n costen deu segons i eviten l'accident més car de la professió.

Reduir un volum lògic en l'ordre equivocat. En ampliar: lvextend i després resize2fs. En reduir: resize2fs primer i després lvreduce. Invertir-ho en reduir talla dades. Fes servir lvresize -r, que ho fa bé tot sol.

Deixar instantànies d'LVM vives indefinidament. Costen un 20-40 % de rendiment d'escriptura i, si s'omplen, s'invaliden i perds la còpia. Crear, fer servir i eliminar.

Recórrer a umount -l com a resposta reflexa al «target is busy». Amaga el problema: el sistema de fitxers continua en ús encara que hagi desaparegut de l'arbre. Diagnostica primer amb lsof o fuser, i atura el servei.

Muntar sistemes de fitxers de xarxa sense nofail. Un NAS apagat bloqueja l'arrencada del servidor. I amb hard, un servidor caigut deixa processos en D que no moren ni amb kill -9.

Consell: munta els volums de dades amb nosuid,nodev,noexec —tres paraules que tanquen tres vectors d'atac— i fes servir findmnt en lloc de mount a seques, que mostra l'arbre, filtra, verifica i retorna codis de sortida útils en scripts.

En una màquina qualsevol, executa lsblk -f, findmnt, blkid i cat /proc/mounts, i respon: (a) quants sistemes de fitxers hi ha muntats i quants tenen un dispositiu real al darrere?; (b) quines opcions té /tmp i què protegeix cadascuna?; (c) quanta RAM estan consumint els tmpfs ara mateix?; (d) crea un fitxer a /dev/shm i localitza on apareix la seva memòria a free -h. Explica el resultat de (d) amb el que saps del VFS i de la memòria cau de pàgines.

Instal·laràs un meteo-02 amb un NVMe d'1 TB i dos discos SATA de 4 TB per a l'històric. Dissenya l'esquema complet: taula de particions (justificant MBR o GPT), particions amb les seves mides i sistemes de fitxers, ús o no d'LVM, i l'/etc/fstab íntegre amb els sis camps i les opcions de muntatge justificades una a una. Explica què protegeix cada separació i què passaria si no la fessis. El servidor executarà els tres serveis de Meteora i guardarà cinc anys d'històric.

/var/lib/meteora és sobre un volum lògic de 600 GB i l'ingestor escriu sense parar. Escriu el script complet de còpia de seguretat nocturna que produeixi una còpia consistent sense aturar el servei: dimensionament justificat de la instantània, la seqüència d'ordres amb el seu control d'errors, la comprovació que la instantània no s'ha desbordat, i la neteja garantida encara que el script falli a la meitat. Explica a més per què sync abans de crear la instantània no n'hi ha prou del tot i què caldria per a una còpia perfecta.

Solució 1

(a) wc -l < /proc/mounts dona el total i grep -c '^/dev/' /proc/mounts els que tenen dispositiu real. En un sistema típic en surten entre 25 i 40 de muntatges, dels quals només 3 a 6 tenen un dispositiu real; tota la resta és procfs, sysfs, tmpfs, devtmpfs, cgroupfs, devpts, securityfs... El sistema de fitxers que veus és majoritàriament una construcció en memòria, i aquesta és la millor demostració pràctica de per a què serveix el VFS.

(b) findmnt /tmp dona una cosa com rw,nosuid,nodev,noexec,relatime,size=2097152k. nosuid impedeix l'escalada amb un binari setuid dipositat allà —/tmp és escrivible per tothom, així que és el lloc natural per intentar-ho—; nodev impedeix crear un /dev/sda casolà i llegir el disc cru; noexec impedeix executar directament un binari descarregat (encara que no bloqueja bash script.sh); i size=2G limita quanta RAM pot consumir.

(c) df -h -t tmpfs: la columna «Usat» de cada tmpfs és RAM ocupada ara mateix, i sol rondar uns quants centenars de MiB entre /run, /dev/shm i /tmp.

(d)

Explicació. tmpfs no té dispositiu: les seves pàgines són pàgines de la memòria cau de pàgines (02-04), així que free les comptabilitza a buff/cache. La diferència amb una memòria cau normal és crucial: les pàgines de tmpfs no es poden descartar, perquè no hi ha còpia en cap disc del qual rellegir-les; només poden anar-se'n a swap. Per això un tmpfs sense size= pot arribar a esgotar la memòria del sistema i disparar l'OOM killer de 02-04, i per això tots els tmpfs del sistema porten un límit.

Solució 2

Taula de particions: GPT, perquè els discos de 4 TB superen el límit de 2 TiB d'MBR; a més aporta redundància i CRC.

Deixar espai sense assignar al VG és una decisió de disseny, no un descuit: com que LVM amplia en calent, és millor repartir quan sàpigues on cal que endevinar-ho el dia de la instal·lació.

Justificació de les opcions no òbvies: errors=remount-ro a / fa que un error d'E/S passi el volum a només lectura en lloc de continuar corrompent-se; nosuid,nodev a /var perquè no hi ha motiu legítim per a un binari setuid allà, però sense noexec perquè alguns gestors de paquets executen coses des de /var/lib; noexec sí a /var/lib/meteora i /srv/historic, que són dades pures; pass=1 només a /, 2 a la resta i 0 a swap i tmpfs, que no tenen fsck; nofail a /srv/historic perquè un RAID que no s'acobli no impedeixi arrencar; i /tmp com a tmpfs de 4 GB, ràpid, autonetejable i amb límit perquè no esgoti la RAM.

Què passaria sense les separacions. Sense /var separat, un registre desbocat ompliria / i no podries iniciar sessió per arreglar-ho. Sense /var/lib/meteora separat, no li podries aplicar noatime ni un mkfs afinat. Sense /boot separat, xifrar el disc arrel seria molt més complicat.

Solució 3

Dimensionament. La instantània emmagatzema els blocs originals de tot el que canviï mentre visqui. Meteora escriu uns 17,3 MB al dia, és a dir 720 KB/hora; si la còpia triga 30 minuts, canviaran uns 360 KB. Amb 10 GB hi ha un factor de seguretat de 28.000× davant d'un pic anòmal, i continua sent l'1,6 % del volum. Sobredimensionar aquí és barat; quedar-se curt significa perdre la còpia.

Les tres decisions importants del script: set -euo pipefail avorta al primer error en lloc de continuar amb una còpia incompleta; trap netejar EXIT garanteix que la instantània s'elimina encara que el script falli o el matin —sense això, una instantània oblidada penalitza les escriptures durant dies i acaba desbordant-se—; i la comprovació posterior de data_percent avisa si la instantània es va omplir durant la còpia, que és el que converteix el script en una còpia de seguretat i no en una il·lusió.

Per què sync no n'hi ha prou del tot. sync aboca la memòria cau de pàgines del nucli al dispositiu, així que la instantània recull tot el que el nucli tenia pendent. Però no buida les memòries intermèdies d'espai d'usuari: si l'ingestor fa servir FILE* de la biblioteca C, pot tenir dades a la seva pròpia memòria intermèdia que encara no han arribat ni tan sols al nucli (04-04). D'aquí el systemctl reload previ, que li demana tancar i reobrir els seus fitxers amb fsync(). La còpia perfecta requereix a més que l'aplicació tingui un punt consistent —una transacció tancada, un fitxer de dia complet— i no només bytes abocats; amb un format de registres de 24 bytes afegits al final, qualsevol tall deixa com a molt una lectura incompleta, que el lector detecta per la mida. És la diferència entre consistència de bytes i consistència d'aplicació, i hi tornarem a 04-05.

Una partició és un rang contigu d'LBA declarat com a unitat independent, i la taula que les descriu és MBR o GPT. L'elecció ja no és opinable: MBR topa a 2 TiB i 4 particions primàries i no té redundància; GPT arriba a 8 ZiB, admet 128 particions, guarda una còpia de la taula al final del disc verificada amb CRC32 i protegeix del formatatge accidental amb un MBR protector. Es particiona per aïllar l'ompliment, aplicar polítiques diferents, fer servir sistemes de fitxers diferents i satisfer els requisits d'arrencada, i la separació de /var té un argument demolidor: un / ple és un servidor on no pots entrar a arreglar-lo. LVM afegeix la capa que a les particions els falta: PV, VG i LV permeten ampliar en calent (lvextend + resize2fs, en aquest ordre; a l'inrevés per reduir), repartir un volum entre discos i moure dades sense aturar res; i les seves instantànies resolen la còpia consistent de /var/lib/meteora sense aturar l'ingestor, a canvi d'un 20-40 % de penalització d'escriptura i del risc d'invalidar-se si s'omplen.

El muntatge és l'operació central del mòdul: resoldre el punt de muntatge, llegir el superbloc, comprovar l'estat, crear el superblock i el vfsmount en memòria i enganxar la dentry perquè la resolució de camins salti al nou arbre. D'aquell últim pas surten dos fets: que muntar sobre un directori no buit oculta el seu contingut sense esborrar-lo, i que la taula de muntatges de /proc/mounts és la veritat del sistema. La identificació estable és amb UUID=, mai amb /dev/sdX, i /etc/fstab té sis camps on pass val 1 a l'arrel, 2 a la resta i 0 al que no té fsck — amb el procediment obligatori de còpia de seguretat, findmnt --verify i mount -a abans de reiniciar.

Les opcions de muntatge són enfortiment gratuït: nosuid talla l'escalada per binari setuid, nodev impedeix llegir el disc cru saltant-se els permisos, noexec afegeix una capa més, i errors=remount-ro atura el dany d'un disc moribund. Per això /var/lib/meteora va amb noatime,nosuid,nodev,noexec. El «target is busy» té quatre causes —fitxer obert, cwd, mmap i muntatge a sobre—, es diagnostica amb lsof o fuser -vm, i es resol aturant el servei: umount -l desenganxa però no allibera, i fuser -k mata sense avisar. Els muntatges bind exposen un mateix arbre en dos punts amb opcions diferents, permeten veure el que està ocult sota un muntatge i són l'avantsala dels espais de noms de muntatge de 06-02.

I l'explicació de fons de tot és el VFS: quatre objectes —superblock per muntatge, inode per fitxer, dentry per nom, file per obertura— i taules de punters a funció que fan que vfs_read() acabi a ext4_file_read_iter, a shmem_file_read_iter o al client NFS segons el cas. Gràcies a ell, /proc pot generar els seus fitxers en llegir-los —d'aquí la mida 0 i el contingut canviant—, tmpfs pot ser un sistema de fitxers el magatzem del qual és la memòria cau de pàgines —i per això /dev/shm/meteora-cache és alhora un fitxer i memòria compartida POSIX—, i NFS pot posar un sistema de fitxers a l'altra banda de la xarxa, amb els seus tres inconvenients: latència per anada i tornada, coherència feble que trenca els bloqueigs, i hard que deixa processos en D quan el servidor cau.

Ja tenim el mapa complet de l'emmagatzematge: sabem què és un fitxer, com se li posa nom, i com s'acobla l'arbre pel qual hi arribem. El que no hem fet encara és fer-lo servir des d'un programa. Què passa exactament quan open() retorna el número 3? Per què pare i fill comparteixen el desplaçament després d'un fork però dos open del mateix fitxer no? Com implementa l'intèrpret d'ordres la redirecció > i aquell 2>&1 que tothom copia sense entendre? I com s'assegura l'agregador que les mitjanes horàries que publica no es llegeixin mai a mig escriure?

És el que veurem a Gestió de Fitxers.