A les dues lliçons anteriors hem comptat el cost d'una fallada de pàgina en mil·lisegons i hem vist un servidor caure en hiperpaginació per culpa del disc. Ara toca mirar de cara aquest component que hem estat tractant com una caixa negra lenta. Perquè no és una caixa negra: un disc mecànic i un SSD NVMe tenen físiques completament diferents, i les decisions que el sistema operatiu pren per a l'un són contraproduents per a l'altre.

Un avís sobre l'abast: aquesta lliçó tracta l'emmagatzematge com a recurs gestionat, no com a sistema de fitxers. Aquí veuràs la física del dispositiu, quant costa un accés, com s'ordenen les peticions i com es combinen diversos discos en un volum fiable. Tot el que té a veure amb fitxers, directoris, inodes, particions i muntatge correspon al mòdul 4. La frontera és clara: aquí gestionem blocs numerats; allà se'ls dona significat.

1. La jerarquia d'emmagatzematge completa
2. El disc dur mecànic per dins
3. Càlcul del temps d'un accés a disc
4. SSD i memòria NAND: una altra física, unes altres regles
5. Amplificació d'escriptura, recollida d'escombraries i TRIM
6. NVMe i per què canvia les regles
7. LBA i l'abstracció del dispositiu de blocs
8. Planificació de peticions de disc
9. Els planificadors reals de Linux
10. RAID: combinar discos per capacitat, velocitat o fiabilitat
11. La decisió de Meteora per a /var/lib/meteora
12. Mesura amb lsblk i iostat -x

A 01-01 vam veure la jerarquia de memòria fins a la RAM. Ara la completem cap avall, que és on les diferències es tornen brutals:

Els salts entre nivells adjacents són de 2 a 5 vegades, tret d'un:

L'abisme és entre la RAM i l'emmagatzematge persistent, i aquest abisme és la raó de ser de la memòria cau de pàgines, de la memòria intermèdia que vam calcular a 01-06 i de la paginació per demanda de la lliçó anterior. Tot el disseny d'un sistema operatiu a la part d'E/S consisteix a evitar creuar-lo.

Una analogia en escala humana, escalant 1 ns a 1 segon:

Quan l'agregador provoca una fallada major, des del punt de vista de la CPU és com esperar tres mesos per una dada.

Un HDD és l'únic component amb parts mòbils en un servidor modern, i la seva física governa tot el seu comportament.

El vocabulari, que cal tenir clar per als càlculs:

El cilindre és un concepte clau: com que tots els capçals es mouen solidàriament, accedir a dades del mateix cilindre no requereix moure el braç, encara que siguin en plats diferents. És pràcticament de franc.

Un accés té tres components de temps:

La latència rotacional mitjana és exactament mitja volta, perquè de mitjana el sector estarà a mig camí:

El calcularem amb les dades del disc de meteo-01:

Cas 1: llegir un bloc de 4 KB en una posició aleatòria.

Observa la proporció, que és el veritablement important:

El 99,8 % del temps es dedica a posicionar-se, no a llegir. Aquesta única xifra explica tot el disseny dels sistemes d'emmagatzematge sobre disc mecànic.

Cas 2: llegir 1 MB contigu.

Llegir 256 vegades més dades només costa un 52 % més de temps.

Cas 3: llegir aquest mateix 1 MB en 256 blocs de 4 KB dispersos.

Comparació directa:

Un disc mecànic és 168 vegades més lent amb accés aleatori que seqüencial. D'aquí en surten tres conseqüències que dominen el disseny de sistemes:

1. Llegir més del que s'ha demanat surt gairebé de franc (lectura anticipada, readahead): ja que has pagat la cerca, aprofita-la.
2. Agrupar escriptures disperses en una de seqüencial compensa enormement, encara que impliqui escriure més bytes. És el fonament dels sistemes de fitxers estructurats en registre i del journaling (04-05).
3. Reordenar les peticions per minimitzar el moviment del braç té un impacte gegantí. És el tema de l'apartat 8.

Aplicat a Meteora, amb els 17 MB diaris de /var/lib/meteora/lectures/:

La mateixa dada, 428 vegades més lenta. Per això l'agregador ha de recórrer el fitxer en ordre, i per això madvise(MADV_SEQUENTIAL) de la lliçó anterior té sentit.

Un SSD no té parts mòbils. Emmagatzema bits com a càrrega elèctrica atrapada en cel·les de memòria flash NAND. Això elimina cerca i latència rotacional, però introdueix restriccions noves i molt peculiars.

L'estructura interna:

I aquí hi ha l'asimetria que ho explica tot:

No es pot sobreescriure una pàgina de flash. Cal esborrar-la abans, i l'esborrat només funciona sobre blocs sencers que són centenars de vegades més grans que la pàgina.

Aquesta restricció, que sembla un detall tècnic menor, té conseqüències en cascada sobre tot el comportament del dispositiu.

Suposa que vols modificar 4 KB dins d'un bloc de 2 MB que és ple de dades. La seqüència ingènua seria:

Has escrit 2 MB a la flash per modificar 4 KB. El factor d'amplificació és de 512.

Cap SSD real no fa això, precisament perquè seria inacceptable. En comptes d'això, el controlador escriu els 4 KB nous en una pàgina ja esborrada d'un altre lloc, i actualitza una taula interna que tradueix adreces lògiques a físiques. La pàgina antiga queda marcada com a invàlida, pendent de reciclatge.

Aquesta taula s'anomena FTL (Flash Translation Layer) i és, conceptualment, una taula de pàgines dins de l'SSD: el mateix mecanisme d'indirecció que vam estudiar a la lliçó anterior, aplicat a l'emmagatzematge. Ni el sistema operatiu ni tu no veieu mai les adreces físiques de la flash.

Com que les pàgines invàlides s'acumulen, l'SSD necessita reciclar-les. Aquest procés és la recollida d'escombraries (garbage collection):

El cost: per alliberar espai s'han hagut de copiar dades que ja estaven escrites. Això és amplificació d'escriptura (write amplification):

Un SSD gairebé ple es comporta molt pitjor que un amb espai lliure. I no és només qüestió de rendiment: la flash té un nombre limitat de cicles d'esborrat per cel·la.

Amb això es pot calcular la vida útil de l'SSD de meteo-01:

La càrrega de Meteora no desgastarà mai l'SSD. Però canvia l'escenari: un servidor de base de dades que escrigui 500 GB/dia amb WA de 5 gastaria 2,5 TB/dia, i aquests mateixos 1.500 TBW durarien 600 dies. Per això el TBW és una especificació que cal mirar en comprar SSD per a servidors d'escriptura intensiva.

Si el controlador escrivís sempre als mateixos blocs, aquests s'esgotarien mentre la resta queda intacta. L'anivellament de desgast (wear leveling) reparteix les escriptures uniformement, i fins i tot mou dades estàtiques que fa molt temps que no canvien per alliberar-ne els blocs poc desgastats.

És una altra de les raons per les quals l'SSD necessita indirecció: la relació entre adreça lògica i ubicació física canvia constantment.

Quan esborres un fitxer, el sistema de fitxers marca els seus blocs com a lliures a les seves pròpies estructures, però l'SSD no se n'assabenta: per a ell, aquestes dades continuen sent vàlides i les continuarà copiant durant la recollida d'escombraries.

L'ordre TRIM (discard a NVMe) comunica a l'SSD quins blocs ja no contenen dades útils:

Sense TRIM, l'SSD acaba creient que és ple encara que el sistema de fitxers vegi espai lliure, i l'amplificació d'escriptura es dispara. Les distribucions modernes activen fstrim.timer setmanalment, que és l'opció recomanada enfront de discard a les opcions de muntatge (aquesta última emet un TRIM per cada esborrat i pot penalitzar el rendiment).

La fila més important és la quarta: en un SSD, l'accés aleatori costa pràcticament el mateix que el seqüencial. Aquesta única diferència invalida dècades d'optimitzacions dissenyades per a discos mecànics, inclosos gairebé tots els algorismes de planificació que veurem tot seguit.

Els primers SSD es connectaven per SATA amb el protocol AHCI, dissenyat el 2004 per a discos mecànics. Els seus supòsits ja no valien:

La diferència estructural és la paral·lelització. Amb AHCI, una única cua significa que tots els nuclis competeixen per ella amb un forrellat compartit. NVMe dona una cua per nucli, eliminant la contenció per complet: cada CPU envia les seves peticions a la seva pròpia cua sense sincronitzar-se amb ningú.

I aquí connecta amb el que sabem: un SSD té 4-8 canals interns treballant en paral·lel. Per saturar-lo calen moltes peticions simultànies en vol. Amb una sola cua de 32 comandes és impossible; amb 65.535 cues, trivial.

La columna ROTA (rotacional) és la que cal mirar: 1 és un disc mecànic, 0 un SSD. El nucli la fa servir per decidir la lectura anticipada, el planificador per defecte i altres polítiques. Comprovar-la és sempre el primer pas en diagnosticar rendiment de disc.

Tot l'anterior —cilindres, capçals, canals NAND, FTL— està ocult. El sistema operatiu veu una abstracció uniforme: el dispositiu de blocs.

Aquesta numeració és el LBA (Logical Block Addressing). Abans de 1990 es feia servir adreçament CHS (cilindre-capçal-sector), que exposava la geometria física i limitava la capacitat a 8 GB. LBA el va substituir per un número seqüencial i el microprogramari del disc fa la traducció.

L'abstracció dona al sistema operatiu exactament quatre operacions:

Aquesta uniformitat és el que permet que el mateix codi del nucli funcioni sobre un disquet, un SSD NVMe, un volum RAID o un disc de xarxa. És la mateixa idea de màquina estesa que vam veure a 01-01, aplicada a l'emmagatzematge. L'operació flush() és especialment important i tornarà a Assignació d'Espai, Journaling i Integritat, perquè un fsync() que no arribi fins al plat físic no garanteix res.

Amb un disc mecànic, l'ordre en què se serveixen les peticions determina quant es mou el braç, i ja sabem que allà hi ha el 99,8 % del cost. És un problema de planificació anàleg al de la CPU, però amb una mètrica diferent: el desplaçament total del capçal.

Treballarem tots els algorismes sobre la mateixa cua:

Se serveixen en l'ordre d'arribada.

El braç creua el disc d'un extrem a l'altre diverses vegades. És just i simple, però pèssim.

Es tria sempre la petició més propera a la posició actual.

Una reducció del 63 % enfront de FCFS. Però SSTF és l'equivalent en disc de SJF, i comparteix el seu defecte: inanició. Si arriben contínuament peticions prop del cilindre 60, la del cilindre 183 pot no servir-se mai.

El capçal es mou en una direcció servint tot el que troba, arriba a l'extrem i torna. Com un ascensor.

Suposem que es mou cap a cilindres menors:

Mateix total que SSTF aquí, però sense inanició: tota petició se serveix com a molt en dos recorreguts complets. Aquesta garantia és el que el fa utilitzable.

El seu defecte: les peticions just darrere del capçal esperen un recorregut sencer, mentre que les de just davant se serveixen immediatament. El temps d'espera no és uniforme.

Només serveix peticions en una direcció; en arribar a l'extrem, torna al principi sense servir res en el retorn.

Recorre més, però a canvi ofereix un temps d'espera molt més uniforme: el disc es comporta com una llista circular i cap zona no està sistemàticament afavorida. És el compromís que solen preferir els sistemes on la previsibilitat importa més que el rendiment mitjà.

Optimització òbvia de SCAN i C-SCAN: no anar fins a l'extrem físic si no hi ha peticions allà.

LOOK:

C-LOOK:

LOOK guanya en desplaçament total i és el que històricament han fet servir els sistemes UNIX. C-SCAN i C-LOOK són preferibles quan la variància de la latència importa més que la mitjana.

I ara l'observació que cal tenir sempre present: tot aquest apartat pressuposa un capçal que es mou. En un SSD, la «distància» entre el LBA 14 i el 183 és zero: tots dos accessos costen el mateix. Reordenar peticions per a un SSD no només no ajuda, sinó que afegeix latència i consumeix CPU sense cap benefici. És exactament el que va motivar el planificador none de Linux.

Linux permet triar el planificador d'E/S per dispositiu:

Els claudàtors indiquen l'actiu. Fixa't en la decisió que ha pres el nucli tot sol: none per al NVMe, mq-deadline per al disc mecànic.

none no fa res: passa les peticions al dispositiu en l'ordre d'arribada. Sona a rendició, però és l'opció correcta per a NVMe: el dispositiu té les seves pròpies cues paral·leles i el seu propi planificador intern, i en sap més que el nucli sobre la seva geometria. Qualsevol reordenació del sistema operatiu seria una suposició equivocada.

mq-deadline manté dues cues ordenades per LBA (una de lectura, una altra d'escriptura) més dues cues FIFO per termini. Serveix en ordre de LBA —cosa que dona un comportament de tipus LOOK— tret que una petició estigui a punt d'esgotar el seu termini, moment en què salta a servir-la. Els terminis per defecte són reveladors:

500 ms per a lectures i 5.000 ms per a escriptures. Les lectures tenen deu vegades més prioritat, i la raó és sòlida: una lectura és gairebé sempre síncrona (hi ha un procés bloquejat esperant-la, en estat D), mentre que una escriptura sol ser asíncrona (el procés ja ha continuat, i el nucli la buidarà quan pugui). Endarrerir una lectura bloqueja algú; endarrerir una escriptura no.

bfq (Budget Fair Queueing) dona a cada procés un pressupost de sectors i reparteix l'amplada de banda de manera justa, amb pesos configurables mitjançant ionice. És el que permetia la solució del backup a la lliçó 02-02:

Canviar el planificador és immediat i no requereix reiniciar:

Per fer-ho persistent es fa servir una regla d'udev, mecanisme que veurem a la propera lliçó.

Regla pràctica d'elecció:

Un disc falla. La probabilitat anual de fallada d'un disc de servidor ronda l'1-2 %, cosa que sembla poc fins que en tens 100: aleshores esperes una o dues fallades l'any amb certesa pràctica.

RAID (Redundant Array of Independent Disks) combina diversos discos en un volum lògic. Els nivells es distingeixen per com reparteixen dades i redundància.

Les dades es reparteixen en franges entre tots els discos. Sense redundància.

• Capacitat: 100 % de la suma.
• Rendiment: multiplica per N en lectura i escriptura.
• Tolerància a fallades: cap. Si falla un disc, es perd tot el volum.

I el parany estadístic: RAID 0 és menys fiable que un disc sol. Amb 4 discos al 2 % de fallada anual:

Multipliques el risc per quatre. Només té sentit per a dades reproduïbles: memòries cau, fitxers temporals, resultats intermedis.

Cada dada s'escriu idèntica a tots els discos.

• Capacitat: 50 % amb dos discos.
• Lectura: es pot repartir entre tots dos, fins a 2× més ràpida.
• Escriptura: la d'un disc (cal escriure als dos).
• Tolera la fallada d'un disc sense perdre res ni degradar-se gairebé gens.

Les dades es divideixen entre N discos i s'hi afegeix un bloc de paritat calculat amb XOR, rotant quin disc el guarda.

La màgia del XOR: si es perd D1, es recupera com D1 = D0 XOR D2 XOR P0. La mateixa operació serveix per calcular i per reconstruir.

• Capacitat: (N−1)/N. Amb 4 discos, el 75 %.
• Tolera una fallada.
• Penalització d'escriptura: modificar un bloc exigeix llegir la dada antiga, llegir la paritat antiga, calcular la nova i escriure dos blocs. Quatre operacions d'E/S per escriptura.

El risc seriós de RAID 5 amb discos grans és la reconstrucció. En substituir un disc de 8 TB cal llegir els altres tres sencers:

Gairebé dos dies amb l'array degradat i sense redundància, sotmetent els discos supervivents —de la mateixa edat i el mateix lot— a una càrrega intensa de lectura. És exactament quan és més probable una segona fallada, i una segona fallada en RAID 5 significa pèrdua total. Per això RAID 5 està desaconsellat amb discos de més de 2 TB.

Com RAID 5 però amb dos blocs de paritat independents.

• Capacitat: (N−2)/N. Amb 6 discos, el 66,7 %.
• Tolera dues fallades simultànies.
• Penalització d'escriptura: sis operacions per escriptura.

És la resposta al problema de reconstrucció de RAID 5: durant les 44 hores de reconstrucció encara queda un nivell de redundància.

Miralls de dos discos, units per divisió.

• Capacitat: 50 %.
• Sense penalització de paritat: dues operacions per escriptura.
• Tolera una fallada per mirall; amb sort, fins a la meitat dels discos.
• Reconstrucció rapidíssima: només cal copiar el disc mirall, no llegir tot l'array.

Amb discos de 8 TB, reconstruir és copiar 8 TB: unes 15 hores, i sense posar en risc la resta de l'array.

Amb 4 discos de 8 TB cadascun:

I l'advertiment imprescindible:

RAID no és una còpia de seguretat. Protegeix de la fallada de maquinari, i de res més. No et salva d'un rm -rf accidental, de ransomware, d'una fallada del sistema de fitxers, d'un error del controlador RAID ni d'un incendi. Una còpia de seguretat és una còpia separada en el temps i en l'espai.

Apliquem-ho tot a un cas concret. Requisits:

Anàlisi d'opcions:

Justificació de RAID 1 amb dos SSD:

1. El volum és petit. 500 GB projectats a 10 anys caben de sobres en 1 TB. Optimitzar capacitat no aporta res aquí, i aquest és precisament l'argument de RAID 5 i 6.
2. L'escriptura és contínua i en append. RAID 5 penalitza amb 4 operacions d'E/S per escriptura; RAID 1 només amb 2. Amb l'ingestor escrivint constantment, aquesta diferència importa més que la capacitat.
3. La reconstrucció és una simple còpia. Substituir un SSD implica copiar com a molt 500 GB, uns 15 minuts a 550 MB/s, sense exposar les dades com faria RAID 5.
4. La lectura millora: agregador i meteo-api poden llegir dels dos discos en paral·lel.
5. Simplicitat. RAID 1 és el nivell més fàcil d'entendre, muntar i recuperar. En una emergència a les tres de la matinada, això val més que un 25 % de capacitat extra.

Configuració:

La línia [2/2] [UU] és la que cal vigilar: dos discos de dos actius, tots dos U (up). Si hi veiessis [2/1] [U_], l'array estaria degradat i caldria substituir un disc amb urgència.

I la part que RAID no cobreix: una còpia diària a un altre servidor, en una altra ubicació física. RAID 1 protegeix de la fallada d'un SSD; només la còpia protegeix d'un rm accidental o d'un incendi al rack.

D'un cop d'ull tens la topologia completa: dos NVMe formant md0 muntat a /var/lib/meteora, un disc mecànic de 7,3 TB per a /backup, i el planificador correcte a cadascun.

iostat -x és l'eina de diagnòstic principal:

Columna a columna, amb el que significa cadascuna:

Lectura d'aquestes dades concretes:

• nvme0n1 i nvme1n1 tenen xifres gairebé idèntiques, com ha de ser en RAID 1: mateixes escriptures a tots dos, lectures repartides.
• md0 suma les lectures (280,5 = 142,5 + 138) però no duplica les escriptures (388), que és exactament el comportament esperat del mirall.
• r_await de 0,08 ms als NVMe. Excel·lent, dins del que és esperable.
• sda és el problema: w_await de 28,4 ms, aqu-sz de 3,44 i %util del 92,1 %. El disc de backup està saturat escrivint 18 MB/s. Com que és un disc mecànic amb escriptura intensiva, és el seu comportament normal, però convé que el backup no competeixi amb res crític (d'aquí el ionice -c 3).
• wrqm/s de 84 a sda: el nucli està fusionant moltes peticions contigües abans d'enviar-les, senyal d'escriptura seqüencial. És el que es vol en un disc mecànic.

Un avís important sobre %util: en discos mecànics és fiable (només poden servir una petició alhora, així que el 100 % significa saturació). En NVMe és enganyosa: el dispositiu serveix desenes de peticions en paral·lel, així que pot marcar el 100 % estant al 5 % de la seva capacitat real. En SSD, la mètrica de referència és await, no %util.

I per mesurar la capacitat real del dispositiu abans de posar res en producció:

487.000 IOPS aleatòries de 4 KB amb 64 µs de latència mitjana. Compara-ho amb les ~120 IOPS d'un disc mecànic: un factor de 4.000.

Aplicar la intuïció del disc mecànic a l'SSD. Desfragmentar un SSD no serveix de res i consumeix cicles d'escriptura. Reordenar peticions tampoc: a la flash no hi ha distància. El primer en analitzar rendiment és mirar lsblk -o NAME,ROTA i saber amb què estàs tractant.

Confiar en %util per a SSD. Un NVMe al 100 % de %util pot estar completament ociós en termes reals. Fes servir await i aqu-sz.

Omplir un SSD al màxim. Per sobre del 90 % d'ocupació, la recollida d'escombraries perd eficàcia i l'amplificació d'escriptura es dispara de 2 a 10. Deixa sempre un 10-20 % lliure; molts SSD de servidor el reserven de fàbrica (over-provisioning).

Fer servir RAID 5 amb discos grans. Amb discos de 8 TB, una reconstrucció de 44 hores sense redundància és un risc real de perdre-ho tot. Per a discos de més de 2 TB, RAID 6 o RAID 10.

Confondre RAID amb còpia de seguretat. RAID protegeix de la fallada d'un disc. No protegeix d'esborrats accidentals, corrupció lògica, ransomware ni desastres físics. Són problemes diferents amb solucions diferents.

Oblidar el TRIM. Sense fstrim.timer actiu, un SSD acaba amb el rendiment d'escriptura degradat sense causa aparent. Comprova-ho amb systemctl status fstrim.timer.

Canviar el planificador d'E/S sense mesurar. El valor per defecte que tria el nucli sol ser correcte. Si el vols canviar, mesura abans i després amb fio o amb la càrrega real; molts canvis «d'optimització» empitjoren les coses.

Consell de diagnòstic: davant d'una sospita de problema de disc, aquest és l'ordre que funciona: lsblk -o NAME,ROTA,SCHED (què tens), iostat -x 2 (mirar await i aqu-sz), iotop -o (quin procés està fent E/S) i cat /proc/mdstat si hi ha RAID (està degradat?). I recorda mirar també la columna b de vmstat: si hi ha processos en estat D, ja saps de la lliçó 02-01 que estan encallats esperant exactament això.

meteo-01 té un disc de backup amb aquestes característiques:

1. Calcula el temps de llegir un bloc de 4 KB aleatori.
2. Calcula el temps de llegir els 17 MB de 2026-08-31.dat de manera seqüencial.
3. Calcula el temps de llegir aquests mateixos 17 MB en blocs de 4 KB dispersos pel disc.
4. Quantes IOPS aleatòries de 4 KB ofereix aquest disc? Compara-ho amb les 487.000 del NVMe.
5. Si l'agregador triga 90 segons a processar el dia llegint el fitxer seqüencialment, quina proporció del temps és CPU i quina proporció és disc?

Un disc de 0 a 4.999 cilindres té el capçal al 2.150 i aquesta cua de peticions:

1. Calcula el desplaçament total del capçal amb FCFS, SSTF, SCAN (cap amunt), C-SCAN (cap amunt), LOOK (cap amunt) i C-LOOK (cap amunt).
2. Ordena'ls de millor a pitjor.
3. Quin triaries si el requisit fos que cap petició no esperés més de 2 recorreguts complets? I si fos minimitzar el temps total?
4. Si aquest dispositiu fos un SSD NVMe, quina seria la teva resposta i per què?

Meteora vol ampliar l'emmagatzematge. Tens 6 discos de 4 TB i aquests requisits:

• Dades de lectures (/var/lib/meteora): 500 GB, crítiques, escriptura seqüencial contínua, lectura intensiva.
• Registres i temporals (/var/log, /tmp): 200 GB, reproduïbles, escriptura intensiva.
• Arxiu històric (/arxiu): 8 TB, s'escriu una vegada i es llegeix rarament, important però no crític.

1. Proposa una configuració RAID per a cadascun dels tres usos, indicant quants discos hi assignes.
2. Calcula la capacitat útil de cada volum.
3. Justifica cada elecció amb els criteris de la lliçó.
4. Calcula el temps de reconstrucció de cada volum si falla un disc (suposa 180 MB/s).
5. Què queda sense cobrir per RAID i què hi faries?

Solució 1

1. Bloc de 4 KB aleatori.

Repartiment del temps:

2. Els 17 MB seqüencialment.

A la pràctica un fitxer de 17 MB no està perfectament contigu, així que hi hauria alguna cerca addicional, però l'ordre de magnitud és correcte: uns 120 ms.

3. Els mateixos 17 MB en blocs dispersos.

La mateixa dada, 459 vegades més lenta. És la diferència entre que l'agregador acabi abans de prendre un cafè o trigui gairebé un minut només a llegir.

4. IOPS aleatòries.

Comparació:

Aquest factor de 6.408 és una de les xifres més importants de la informàtica de l'última dècada. Explica per què bases de dades que eren inviables van passar a ser trivials, i per què moltes optimitzacions de programari dissenyades per minimitzar E/S aleatòria van deixar de tenir sentit.

Una lectura complementària de la dada: 76 IOPS significa que aquest disc no pot servir ni 76 peticions aleatòries per segon. Si meteo-api rep 40 peticions/segon i cadascuna provoca 2 lectures aleatòries, aquest disc ja és al límit.

5. Repartiment CPU/disc en els 90 segons.

L'agregador està limitat per CPU, no per disc. Això confirma quantitativament el que vam deduir a 02-02 a partir dels seus canvis de context (proporció de 63 a 1 entre voluntaris i involuntaris, molt inferior a la dels altres processos).

La conseqüència pràctica és important: canviar el disc de backup per un NVMe no acceleraria gens l'agregador. Estalviaries 0,1 segons de 90. Per accelerar-lo cal optimitzar el càlcul, paral·lelitzar-lo o donar-li més CPU. És el tipus de conclusió que evita gastar diners en el component equivocat, i per això es mesura abans de comprar.

Nota: aquest càlcul canviaria completament si l'agregador llegís de manera aleatòria. En aquest cas serien 54,7 s de disc enfront de 90 s totals, un 61 % de disc, i la conclusió s'invertiria.

Solució 2

Cua: 2069, 1212, 2296, 2800, 544, 1618, 356, 1523, 4965, 3681. Capçal al 2150. Disc de 0 a 4999.

Ordenades: 356, 544, 1212, 1523, 1618, 2069, | 2150 | , 2296, 2800, 3681, 4965

FCFS:

SSTF:

SCAN (cap amunt, fins a 4999):

C-SCAN (cap amunt, salt de 4999 a 0):

LOOK (cap amunt, sense arribar a l'extrem):

C-LOOK:

2. Classificació:

3. Elecció segons el requisit.

Si cap petició no ha d'esperar més de dos recorreguts complets: SCAN, C-SCAN, LOOK o C-LOOK, tots vàlids. El determinant és descartar SSTF, que no ofereix aquesta garantia: si arribessin contínuament peticions prop del 2150, la del 4965 podria no servir-se mai. Que en aquest cas concret SSTF doni bon resultat no canvia res; la garantia és sobre el pitjor cas, no sobre un exemple. Entre els quatre vàlids, C-LOOK és la millor opció si a més es vol que l'espera sigui uniforme, perquè no afavoreix sistemàticament cap zona del disc.

Si l'objectiu és minimitzar el temps total: LOOK, amb 7.424 cilindres. Guanya perquè no malbarata moviment anant a extrems buits (34 cilindres de més a SCAN) ni fent el retorn improductiu de les variants circulars.

Nota metodològica: la diferència entre LOOK (7.424) i SSTF (7.586) és només del 2,1 %. Amb una altra cua SSTF podria guanyar. L'avantatge sòlid de LOOK no és el 2 %, sinó la garantia de no inanició al mateix preu.

4. Si fos un SSD NVMe: none, i cap d'aquests algorismes.

El raonament complet:

• La mètrica perd el sentit. «Desplaçament total del capçal» mesura moviment físic d'un braç. A la flash no hi ha braç. Accedir al LBA 356 i al 4965 costa exactament el mateix: uns 50 µs.
• Reordenar és contraproduent. Ordenar peticions consumeix CPU i afegeix latència a la cua del nucli, a canvi d'un benefici que és zero. Estàs pagant per no obtenir res.
• El dispositiu en sap més. L'SSD té la seva pròpia FTL, els seus 4-8 canals paral·lels i el seu propi planificador intern, que coneix la ubicació física real —invisible per al nucli a causa de l'anivellament de desgast—. Qualsevol ordre que imposi el sistema operatiu es basa en una geometria que no existeix.
• NVMe vol paral·lelisme, no ordre. Amb 65.535 cues, l'òptim és enviar les 10 peticions alhora i deixar que el dispositiu les serveixi en paral·lel pels seus diferents canals. Serialitzar-les en un ordre «òptim» destrueix precisament l'avantatge del NVMe.

Estimació del resultat: les 10 peticions, enviades en paral·lel amb una latència de ~50 µs cadascuna i prou paral·lelisme intern, es completarien en aproximadament 50-100 µs en total. Amb el disc mecànic i LOOK, 7.424 cilindres de desplaçament suposen de l'ordre de 150-200 ms. Un factor d'unes 2.000 vegades, obtingut no per planificar millor sinó per deixar de planificar.

Solució 3

1 i 2. Configuració proposada.

Detall dels càlculs:

Les dades crítiques (500 GB) i les reproduïbles (200 GB) caben juntes al RAID 1 de 4 TB amb marge de sobres, en subvolums o particions lògiques diferents. Dedicar discos a part a /var/log seria malbaratar dos discos de 4 TB per a 200 GB.

3. Justificació de cada elecció.

/var/lib/meteora en RAID 1:

• Criticitat màxima. Les lectures perdudes són irrecuperables, així que la redundància és innegociable.
• Escriptura seqüencial contínua. RAID 1 costa 2 operacions d'E/S per escriptura; RAID 5 en costa 4 (llegir dada, llegir paritat, escriure dada, escriure paritat). Amb l'ingestor escrivint sense parar, aquesta diferència es paga cada segon.
• Lectura intensiva. RAID 1 permet servir lectures des dels dos discos en paral·lel, cosa que beneficia directament l'agregador i meteo-api.
• La capacitat sobra. 500 GB de necessitat enfront de 4 TB disponibles: no hi ha cap argument per sacrificar rendiment o simplicitat a canvi de més espai.

/var/log i /tmp al mateix RAID 1:

• Són reproduïbles, així que tècnicament RAID 0 n'hi hauria prou. Però dedicar-los discos propis seria malgastar 8 TB bruts per a 200 GB.
• Conviure amb les dades crítiques els dona redundància de franc, cosa que és un extra benvingut: perdre els registres justament quan estàs diagnosticant una fallada de disc és exactament el pitjor moment possible.
• Precaució necessària: /var/log creixent sense control podria omplir el volum i bloquejar l'escriptura de lectures. Cal posar-li límit amb logrotate i journald (SystemMaxUse=), o aïllar-lo en un subvolum amb quota.

/arxiu en RAID 5:

• Aquí sí que mana la capacitat: 8 TB necessaris de 12 TB útils. RAID 10 amb els mateixos 4 discos donaria només 8 TB, just al límit i sense marge de creixement.
• S'escriu una vegada i es llegeix rarament. La penalització d'escriptura de RAID 5 és irrellevant en una càrrega que gairebé no escriu: és precisament l'escenari per al qual RAID 5 va ser dissenyat.
• És important però no crític: si es perdés, seria recuperable des de les còpies de seguretat i des del reprocessament de les dades originals.
• Els discos són de 4 TB, no de 8, cosa que situa la reconstrucció en un rang acceptable, com veurem al punt següent.

4. Temps de reconstrucció a 180 MB/s.

RAID 1 (4 TB):

I amb només 700 GB de dades reals, moltes implementacions (mdadm amb bitmap, o ZFS/btrfs) copien únicament els blocs usats:

Durant la reconstrucció, el disc supervivent continua servint peticions amb normalitat.

RAID 5 (4 discos de 4 TB):

Comparació i risc:

Les 18,5 hores de RAID 5 són acceptables —molt lluny de les 44 hores del cas de 8 TB que vèiem a la lliçó— però mereixen dues precaucions concretes:

La comprovació periòdica és la més important de les tres: l'escenari que mata RAID 5 és descobrir un sector il·legible al disc B justament durant la reconstrucció del disc A. Llegir tot l'array cada setmana detecta aquests sectors mentre encara hi ha redundància per reparar-los.

5. El que RAID no cobreix.

RAID protegeix exclusivament de la fallada física d'un disc. Queda fora:

La regla de referència és 3-2-1: tres còpies de les dades, en dos mitjans diferents, amb una fora de l'emplaçament.

--link-dest crea enllaços durs cap a la còpia anterior, de manera que cada dia ocupa només el que ha canviat però es veu com una còpia completa i independent. Amb 17 MB diaris, un any d'historial diari ocupa uns 6,2 GB en lloc de 6,2 TB.

I una última peça que sempre s'oblida: una còpia de seguretat que no s'ha restaurat mai no és una còpia de seguretat, és una esperança. Cal programar una restauració de prova periòdica i verificar que les dades recuperades són llegibles i correctes.

L'emmagatzematge és el nivell de la jerarquia on apareix l'abisme: de la RAM a l'SSD hi ha un factor de 500, i al disc mecànic de 80.000. Tot el disseny del subsistema d'E/S consisteix a evitar creuar-lo.

Un disc mecànic gasta el 99,8 % del temps posicionant-se —cerca més latència rotacional— i només el 0,2 % transferint, cosa que el fa 168 vegades més lent en accés aleatori que seqüencial. D'aquí surten la lectura anticipada, l'agrupació d'escriptures i tota la planificació de peticions. Un SSD inverteix les regles: sense parts mòbils, l'accés aleatori costa el mateix que el seqüencial, però introdueix restriccions pròpies —no es pot sobreescriure sense esborrar el bloc sencer— que obliguen a una FTL, a la recollida d'escombraries, a l'anivellament de desgast i a TRIM, i que fan que un SSD gairebé ple es comporti molt pitjor que un amb espai. NVMe no és només un connector més ràpid: substitueix una cua per 65.535 i elimina la contenció entre nuclis.

Sobre aquesta física, el sistema operatiu aixeca l'abstracció del dispositiu de blocs adreçat per LBA, amb només quatre operacions, que és el que permet que el mateix codi serveixi per a un disquet i per a un array RAID. La planificació de peticions —FCFS, SSTF, SCAN, C-SCAN, LOOK, C-LOOK— redueix el desplaçament fins a un 67 %, però només té sentit si hi ha un capçal per moure: en NVMe l'elecció correcta és none, és a dir, no planificar. Els planificadors reals de Linux reflecteixen exactament això, i mq-deadline incorpora a més una asimetria molt raonada: les lectures tenen un termini deu vegades més curt que les escriptures, perquè darrere d'una lectura gairebé sempre hi ha un procés bloquejat en estat D.

RAID combina discos per capacitat, velocitat o fiabilitat, i l'elecció depèn del patró: RAID 1 per a dades crítiques amb escriptura contínua i volum petit —el cas de /var/lib/meteora—, RAID 5 només amb discos moderats i escriptura escassa, RAID 6 o 10 quan la reconstrucció seria llarga. I l'advertiment que mai no sobra: RAID no és una còpia de seguretat. Finalment, lsblk et diu què tens i iostat -x com es comporta, amb await com a mètrica de referència i %util com a parany en SSD.

Fins aquí hem tractat el disc com el dispositiu. Però un servidor té targetes de xarxa, terminals, rellotges, sensors i controladors de tota mena, i el sistema operatiu ha d'oferir una interfície coherent per a tots ells sense conèixer els detalls de cap. Com ho aconsegueix —la classificació en dispositius de bloc, caràcter i xarxa, el principi que tot és un fitxer, /dev i udev, i les tres maneres que té la CPU de parlar amb un dispositiu— és el que veurem a Gestió de Dispositius.