L2ARC de ZFS en SSD SATA: cuándo merece la pena

Qué es realmente L2ARC (y qué no lo es)

El caché de ZFS empieza con ARC: una caché en RAM que contiene datos y metadatos. ARC es rápida, adaptativa y oportunista.
Cuando ARC es demasiado pequeña para tu conjunto de trabajo, ZFS puede extenderla a un segundo nivel: L2ARC, normalmente en SSD.

Qué es L2ARC

• Una caché de lectura para datos que salieron del ARC. No es «una capa mágica en SSD». Es una segunda oportunidad para servir lecturas sin ir a discos giratorios.
• Almacenamiento persistente que mantiene bloques cacheados, indexados por ARC. El SSD guarda los bloques; la RAM mantiene el índice (headers) que indica a ZFS qué hay en el SSD.
• Ideal para lecturas repetidas. Si tu carga de trabajo no vuelve a leer bloques, L2ARC se convierte en una cinta de correr de escrituras con poco retorno.

Qué no es L2ARC

• No es una caché de escritura. Eso es territorio de SLOG para escrituras síncronas, y aún así solo para registro de intenciones, no para «acelerar escrituras».
• No sustituye a la RAM. ARC vive en RAM y hace el trabajo pesado. L2ARC es un complemento, no un reemplazo.
• No cura un diseño de pool malo. Si tu layout de vdevs es incorrecto para lecturas aleatorias, L2ARC puede enmascarar síntomas brevemente y luego dejarte con la misma enfermedad.

La característica de L2ARC que más se malinterpreta es la sobrecarga en RAM. No obtienes «1 TB de caché gratis» solo porque los SSD SATA son baratos.
El índice de L2ARC consume memoria, y privar al ARC para alimentar L2ARC es como saltarse el desayuno para comprar un cinturón más grande.

Una cita para mantener en mente mientras ajustas cachés: «La esperanza no es una estrategia.» — Vince Lombardi.
También aplica al rendimiento de almacenamiento, solo que con más iostat.

Datos interesantes e historia (porque el contexto cambia decisiones)

1. ARC precede a la actual cultura cloud de «cachear todo». ZFS salió con ARC a mediados de los 2000, cuando la RAM era lo bastante cara como para hacer llorar a ingenieros adultos.
2. L2ARC fue diseñado para discos lentos. Los primeros despliegues de ZFS usaban HDD SATA; L2ARC era un parche práctico para lecturas aleatorias sin reconstruir pools.
3. Originalmente L2ARC se calentaba lentamente tras reiniciar. El comportamiento inicial requería repoblar la caché después de cada reinicio; luego OpenZFS añadió características para reconstruir el estado de L2ARC más rápido (depende de la plataforma).
4. L2ARC se «escribe» según se alimenta, no se replica por defecto. Si pierdes el dispositivo de caché, la seguridad de datos está bien; solo cae el rendimiento al nivel base.
5. ARC puede cachear metadatos agresivamente. Para muchas cargas reales, el cacheo de metadatos (recorridos de directorio, búsquedas de archivos pequeños) domina la sensación de velocidad.
6. ZFS tiene múltiples roles de «almacenamiento rápido» hoy. L2ARC, SLOG, special vdevs y hasta las tablas de deduplicación exigen características distintas en los SSD.
7. Los SSD SATA estrecharon la brecha en rendimiento, no en latencia. La interfaz SATA limita el ancho de banda y suele tener mayor latencia que NVMe; L2ARC suele ser sensible a la latencia.
8. L2ARC puede aumentar las lecturas servidas rápido, pero también aumentar las escrituras totales. Alimentar la caché es una carga de escritura que te estás autoimponiendo.

Chiste #1: Añadir L2ARC para arreglar un pool lento es como instalar un turbo en una furgoneta de reparto con ruedas cuadradas. Hará ruido. No te hará feliz.

Cuándo tiene sentido un L2ARC en SSD SATA

L2ARC en SSD SATA merece la pena cuando tienes tres cosas a la vez:
(1) una carga de trabajo orientada a lecturas, (2) un conjunto de trabajo que no cabe en ARC y (3) suficiente RAM libre para mantener el índice de L2ARC sin expulsar ARC útil.
Si falta alguna, básicamente estás comprando complejidad.

Cargas que tienden a beneficiarse

• Tormentas de lectura en virtualización: Muchas VM arrancando o parcheando en paralelo, tocando bloques OS y librerías compartidas similares repetidamente.
• Paneles analíticos / BI: Escaneos repetidos de los mismos conjuntos de datos, a menudo en ráfagas alineadas con horas de negocio.
• Flotas web/app con muchas lecturas de código: Despliegues fríos pueden causar thrash, pero en estado estable tienden a volver a leer los mismos binarios y plantillas.
• Servidores de archivos con contenido compartido «caliente»: Librerías CAD, artefactos de compilación, toolchains compartidos que muchos clientes leen repetidamente.

Señales de que eres candidato

• Las IOPS de lectura en disco son altas y mayormente aleatorias.
• La ratio de aciertos de ARC es razonable pero limitada porque el conjunto de trabajo es más grande que la RAM.
• La latencia de lectura te limita, no la CPU, ni la red, ni las escrituras sincronas.
• Tu dispositivo L2ARC puede sostener escrituras sin morir joven o sin estrangularse durante la alimentación de caché.

L2ARC en SATA también es un buen «arreglo temporal» en la realidad corporativa: a menudo puedes añadir un par de SSD SATA más rápido que conseguir aprobación de presupuesto para «reconstruir el pool con más vdevs»
o «mover a NVMe». Solo no confundas «rápido de implementar» con «arquitectónicamente correcto».

Cuándo no ayudará (y qué hacer en su lugar)

No ayudará si estás limitado por escrituras

Si los usuarios se quejan durante ingestión, backups, escrituras secuenciales grandes o picos de commits de bases de datos, L2ARC no te salvará.
L2ARC no acelera escrituras, y puede robar recursos de las escrituras al añadir alimentaciones de caché en segundo plano.

Haz esto en su lugar: evalúa SLOG para latencia de escrituras síncronas; añade vdevs para IOPS de escritura; ajusta recordsize; revisa ajustes de sync y patrones de fsync de la aplicación.

No ayudará si tu carga es mayoritariamente de un solo paso

L2ARC es para re-lecturas. Si haces streaming de logs una vez, escaneos de backups únicos o ETL que toca cada bloque una vez al día, L2ARC se llenará con datos que nunca volverás a pedir.
Eso es solo amplificación de escritura con sentido del deber.

Haz esto en su lugar: añade RAM (ARC más grande), añade más discos/vdevs, o mueve el dataset caliente a un vdev especial o a un pool rápido.

No ayudará si la topología del pool es el verdadero cuello de botella

Un vdev RAIDZ de HDD grandes es genial para capacidad, no para IOPS aleatorios. L2ARC puede reducir lecturas aleatorias, pero no cambiará la habilidad fundamental del pool para atender misses.
Si tu tasa de misses sigue alta, seguirás viviendo con la latencia de HDD.

Haz esto en su lugar: rediseña el layout de vdevs (más vdevs, espejos para IOPS), o coloca los datasets realmente calientes en almacenamiento SSD/NVMe.

No ayudará si tienes poca memoria

Si ARC ya está reduciéndose por presión de memoria (contenedores, JVMs, bases de datos o simplemente poca RAM), L2ARC puede empeorar el rendimiento añadiendo overhead.
Tu sistema pasará tiempo haciendo malabarismos con cachés en vez de servir lecturas.

Haz esto en su lugar: añade RAM primero. ARC suele ser la ganancia de rendimiento más barata y rápida en el mundo ZFS.

Chiste #2: L2ARC en un host sin RAM es como alquilar un trastero porque tu casa está desordenada. Aún no encuentras las llaves.

Cómo funciona L2ARC en la práctica: calentamiento, alimentación y fallos

El ciclo de vida de un bloque cacheado

Un bloque se lee. Si se usa lo suficiente, ARC lo mantiene. Cuando ARC necesita espacio, algunos bloques se expulsan.
Los bloques expulsados son candidatos para L2ARC: ZFS puede escribirlos al SSD para que futuras lecturas den en L2ARC en vez de en disco.

Eso implica dos realidades importantes:

• L2ARC se popula por expulsión. Si ARC nunca se llena, L2ARC permanece mayormente inactivo. Si ARC churnea, L2ARC se alimenta agresivamente.
• El tiempo de calentamiento importa. No añades L2ARC y ganas al instante. La caché necesita poblarse con los bloques correctos, y eso lleva tiempo de carga real.

Calentamiento tras reinicio: el dolor práctico

Muchos entornos reinician por actualizaciones del kernel, firmware o el ocasional «por qué está chillando el BMC». Si L2ARC no retiene un estado usable tras reinicio en tu plataforma/config,
sentirás una caída de rendimiento hasta que la caché se repueble. Por eso algunos equipos juran que L2ARC «no sirve» — miden justo después de un reinicio y lo descartan.

Alimentar L2ARC cuesta I/O

ZFS escribe en L2ARC en segundo plano. Eso es ancho de banda de escritura en el SSD, además de CPU y memoria para la contabilidad.
Si el SSD es un modelo SATA de consumo con rendimiento sostenido débil y estrangulamiento térmico agresivo (sí, algunos SATA también lo hacen),
la caché puede volverse auto-limitante: no puede aceptar nuevos bloques cacheados lo bastante rápido para ser útil.

La latencia importa más que el ancho de banda

Los aciertos en L2ARC evitan la latencia de HDD. Bien. Pero la latencia de SSD SATA sigue siendo mucho mayor que la de ARC. Así que L2ARC es mejor visto como «más rápido que HDD, más lento que RAM.»
Si tu carga es extremadamente sensible a la latencia (bases de datos, sistemas interactivos) y los misses son comunes, puede que necesites NVMe o más RAM en su lugar.

Dimensionado y selección de dispositivo SATA para no quedar mal

Empieza con la regla aburrida: añade RAM antes que L2ARC

Los aciertos en ARC son el estándar de oro. Añadir RAM incrementa ARC sin coste extra de I/O y con mínima complejidad. Si puedes añadir RAM, hazlo primero.
L2ARC es para cuando la RAM ya es «razonable» y el conjunto de trabajo sigue sin caber.

¿Qué tamaño debería tener L2ARC?

Dimensiona para el conjunto de re-lectura que no cabe en ARC, no para «el SSD que teníamos en un cajón».
Un L2ARC de 4 TB en una caja con RAM modesta puede ser contraproducente: quemas memoria en indexado y aun así no cacheas lo correcto lo suficientemente rápido.

Prácticamente:

• Pequeño y efectivo vence a enorme e inactivo. Empieza con algo como 5–10× tu tamaño de ARC para L2ARC solo si tienes suficiente RAM libre y una carga de re-lecturas probada.
• Vigila el overhead y la ratio de aciertos. Si la ratio de aciertos de L2ARC se mantiene baja, más grande no lo arreglará; solo será una máquina de misses más costosa.

Elige el SSD SATA como si esperases que se abuse (porque lo hará)

L2ARC escribe de forma continua en muchas cargas. Los SSD SATA de consumo pueden ser aceptables para cachés ligeros, pero en producción suelen ser el eslabón débil:
resistencia de escritura limitada, comportamiento impredecible en escrituras sostenidas cuando se agota la caché SLC y rarezas de firmware.

Lo que quieres:

• Protección contra pérdida de energía (PLP) si es posible. No es por integridad de datos (la caché es prescindible), sino para evitar comportamientos extraños y corrupción ante cortes de energía repentinos.
• Rendimiento de escritura sostenido decente. No números pico de benchmark; busca escrituras estables a largo plazo.
• Resistencia adecuada a tu tasa de alimentación. Si tu alimentación de caché escribe cientos de GB/día, planifica la resistencia en consecuencia.
• Estabilidad térmica. Un SSD SATA atascado detrás de un panel frontal sin flujo de aire se estrangulará y sabotea tu ratio de aciertos.

Un dispositivo o dos?

Los dispositivos L2ARC no suelen ser espejados. Perder un dispositivo L2ARC no es un evento de pérdida de datos; es un evento de rendimiento.
Dicho esto, si tu plataforma soporta añadir múltiples dispositivos de caché, repartir L2ARC en dos SSD puede ayudar el rendimiento y reducir la contención en un solo dispositivo.
La pregunta mayor es operativa: ¿puedes detectar fallos rápido y reemplazar sin drama?

No confundas L2ARC con un vdev especial

Un vdev especial (donde se soporte/usen) puede almacenar metadatos y bloques pequeños en SSD, lo que puede ser transformador para cargas de archivos pequeños.
Pero no es «caché». Pasa a ser parte del pool; si falla y no es redundante, puedes perder datos. Eso es una clase de compromiso diferente.
L2ARC es desechable por diseño.

Guía rápida de diagnóstico

Cuando el rendimiento es malo, no tienes tiempo para una discusión filosófica sobre cachés. Necesitas localizar el cuello de botella rápido.
Aquí está el orden que suele producir respuestas en minutos, no días.

1) Confirma qué tipo de dolor es: latencia de lectura, latencia de escritura, CPU o memoria

• Revisa la latencia y utilización de I/O del pool.
• Revisa el tamaño de ARC y la presión de expulsión.
• Revisa si la carga es intensiva en escrituras síncronas.

2) Si estás limitado por latencia de lectura, determina si son misses de caché o aciertos lentos

• ¿Ratio de aciertos de ARC alta? Probablemente no necesitas L2ARC; necesitas más CPU, mejor checksum o ajuste de aplicación.
• ¿Ratio de aciertos de ARC moderada/baja y discos ocupados? Candidato para aumentar ARC, L2ARC o rediseño del pool.
• ¿Ratio de aciertos de L2ARC baja después del calentamiento? La carga no re-lee; no sigas alimentando la bestia.

3) Si consideras L2ARC, valida el comportamiento del SSD bajo escrituras sostenidas

• Mira las tasas de alimentación de L2ARC y el ancho de banda de escritura del SSD.
• Revisa SMART, desgaste y contadores de errores.
• Confirma que el SSD no esté saturando el controlador SATA o compartiendo lanes con otros dispositivos.

4) Re-prueba durante la misma ventana de carga

L2ARC depende de la carga y del tiempo. Mide durante la ventana ocupada que duele, no a las 2 a.m. cuando todo está frío y tranquilo.

Tareas prácticas: comandos, salidas, decisiones (12+)

El punto de estas tareas es simple: ejecutas un comando, lees la salida y tomas una decisión. Sin misticismo. Todos los ejemplos asumen un sistema Linux con OpenZFS.
Sustituye nombres de pool/dataset para que coincidan con tu entorno.

Task 1: Identify whether the pool is read-latency bound

cr0x@server:~$ zpool iostat -v tank 2 3
                              capacity     operations     bandwidth
pool                        alloc   free   read  write   read  write
--------------------------  -----  -----  -----  -----  -----  -----
tank                        12.3T  7.10T    980    140  92.1M  10.8M
  raidz2-0                  12.3T  7.10T    980    140  92.1M  10.8M
    sda                         -      -    160     25  15.1M   2.0M
    sdb                         -      -    165     23  15.3M   1.9M
    sdc                         -      -    162     24  15.2M   2.0M
    sdd                         -      -    161     22  15.1M   1.8M
    sde                         -      -    165     23  15.2M   1.9M
    sdf                         -      -    167     23  15.2M   1.9M
--------------------------  -----  -----  -----  -----  -----  -----

Qué significa: Las lecturas dominan las operaciones. Si los usuarios reportan lecturas lentas y los discos están ocupados, el cacheado puede ayudar.
Decisión: Continúa con las comprobaciones de ARC/L2ARC; no te lances al SLOG.

Task 2: Check latency directly (the “is it the disks?” test)

cr0x@server:~$ iostat -x 2 3
Linux 6.6.0 (server)  12/26/2025  _x86_64_  (24 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           6.12    0.00    2.04    9.55    0.00   82.29

Device            r/s     w/s   rMB/s   wMB/s  avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda             128.0    20.1    15.1     2.0    136.5     8.20   58.2   60.1   46.3   7.6   99.5
sdb             131.2    19.4    15.3     1.9    135.9     8.05   56.7   59.0   44.8   7.4   99.1

Qué significa: Await ~55–60ms y %util ~99% indican que los discos están saturados. Esto es dolor clásico de lecturas aleatorias en vdevs HDD.
Decisión: Si la carga re-lee datos, L2ARC puede reducir las lecturas de disco; de lo contrario necesitas más vdevs o almacenamiento más rápido.

Task 3: Verify ARC size and pressure

cr0x@server:~$ arcstat 2 3
    time  read  miss  miss%  dmis  dm%  pmis  pm%  mmis  mm%  arcsz     c  avail
12:01:10  9820  2810     28   420    4  2390   24    95    1   38G   48G   12G
12:01:12 10110  3120     30   455    4  2665   26    98    1   38G   48G   11G
12:01:14  9905  3010     30   440    4  2570   26    92    1   38G   48G   11G

Qué significa: ARC está ~38G con objetivo (c) 48G; tasa de misses ~28–30% es significativa.
Decisión: Si se puede aumentar RAM, hazlo. Si no, L2ARC podría ayudar—la siguiente comprobación es si la carga re-lee y si L2ARC ya está presente.

Task 4: Check whether L2ARC exists and how it’s behaving

cr0x@server:~$ arcstat -f time,read,miss,arcsz,l2hits,l2miss,l2read,l2asize 2 3
    time  read  miss  arcsz  l2hits  l2miss  l2read  l2asize
12:02:20  9820  2810   38G     620    2190    6200     480G
12:02:22 10110  3120   38G     700    2420    7100     480G
12:02:24  9905  3010   38G     655    2355    6600     480G

Qué significa: L2ARC existe (l2asize 480G). Hay l2hits pero no son dominantes.
Decisión: Si l2hits crecen durante la carga y las lecturas de disco bajan, L2ARC está ayudando. Si l2hits quedan cerca de cero tras horas/días, probablemente es desperdicio.

Task 5: Validate L2ARC device presence in ZFS

cr0x@server:~$ zpool status tank
  pool: tank
 state: ONLINE
  scan: scrub repaired 0B in 05:22:11 with 0 errors on Sun Dec 21 03:10:12 2025
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          raidz2-0                  ONLINE       0     0     0
            sda                     ONLINE       0     0     0
            sdb                     ONLINE       0     0     0
            sdc                     ONLINE       0     0     0
            sdd                     ONLINE       0     0     0
            sde                     ONLINE       0     0     0
            sdf                     ONLINE       0     0     0
        cache
          ata-SAMSUNG_SSD_870_EVO_1TB_S6PNNX0R123456A  ONLINE       0     0     0

errors: No known data errors

Qué significa: El SSD está adjunto como dispositivo de caché.
Decisión: Si haces troubleshooting, ahora sabes qué dispositivo físico revisar (SMART, cableado, controlador).

Task 6: Add a SATA SSD as L2ARC (carefully)

cr0x@server:~$ sudo zpool add tank cache /dev/disk/by-id/ata-SAMSUNG_SSD_870_EVO_1TB_S6PNNX0R123456A
cr0x@server:~$ zpool status tank
  pool: tank
 state: ONLINE
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          raidz2-0                  ONLINE       0     0     0
            sda                     ONLINE       0     0     0
            sdb                     ONLINE       0     0     0
            sdc                     ONLINE       0     0     0
            sdd                     ONLINE       0     0     0
            sde                     ONLINE       0     0     0
            sdf                     ONLINE       0     0     0
        cache
          ata-SAMSUNG_SSD_870_EVO_1TB_S6PNNX0R123456A  ONLINE       0     0     0

Qué significa: El vdev de caché se ha añadido.
Decisión: Documenta el cambio y abre una ventana de medición. Si no puedes medir mejora, no lo mantengas «porque da buena sensación».

Task 7: Check if memory is being squeezed (L2ARC can worsen this)

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:           128Gi        96Gi       2.1Gi       1.2Gi        30Gi        18Gi
Swap:           16Gi       3.5Gi        12Gi

Qué significa: La memoria disponible es solo 18Gi, swap está en uso. ARC puede estar compitiendo con aplicaciones.
Decisión: Si hay swapping bajo carga, añadir L2ARC es una bandera roja. Soluciona presión de memoria primero (RAM, colocación de cargas, límites ARC).

Task 8: Verify ARC limits (prevent ZFS from eating the whole host)

cr0x@server:~$ cat /sys/module/zfs/parameters/zfs_arc_max
68719476736
cr0x@server:~$ cat /sys/module/zfs/parameters/zfs_arc_min
17179869184

Qué significa: ARC max es 64GiB, min 16GiB (valores en bytes).
Decisión: En hosts de uso mixto, limita ARC para dejar margen. Si añades L2ARC, puede que necesites más margen, no menos.

Task 9: Check L2ARC feed/write behavior (is the SSD getting hammered?)

cr0x@server:~$ grep -E "l2arc_write|l2arc_feed" /proc/spl/kstat/zfs/arcstats | head
l2arc_write_bytes                        4    982374982374
l2arc_write_issued                        4    1293847
l2arc_feed_calls                          4    9182
l2arc_feed_bytes                          4    982374982374

Qué significa: L2ARC ha escrito ~982GB (desde el arranque/carga del módulo). Si ese número sube rápido, la resistencia y el estrangulamiento son preocupaciones reales.
Decisión: Si la tasa de alimentación es enorme y la ratio de aciertos es débil, desactiva L2ARC o reduce la agresividad de la alimentación (donde existan tunables apropiados y probados).

Task 10: Check SSD health and wear (SATA SSD reality check)

cr0x@server:~$ sudo smartctl -a /dev/sdg | egrep "Model Number|Power_On_Hours|Media_Wearout|Percentage Used|Total_LBAs_Written|Reallocated|CRC_Error"
Model Number:                       Samsung SSD 870 EVO 1TB
Power_On_Hours:                    12890
Percentage Used:                   12%
Total_LBAs_Written:                1823749821
Reallocated_Sector_Ct:             0
UDMA_CRC_Error_Count:              0

Qué significa: «Percentage Used» es un indicador de desgaste; errores CRC pueden indicar problemas de cableado/controlador.
Decisión: Si el desgaste sube rápido o aparecen errores CRC, trata el dispositivo de caché como un componente bajo estrés y planifica reemplazo o cambio de estrategia.

Task 11: Confirm SATA link speed and negotiated mode (avoid accidental 1.5Gbps embarrassment)

cr0x@server:~$ sudo smartctl -a /dev/sdg | egrep "SATA Version|SATA.*current"
SATA Version is:  SATA 3.3, 6.0 Gb/s (current: 6.0 Gb/s)

Qué significa: El SSD está funcionando a 6.0 Gb/s. Si muestra 1.5 o 3.0, tu controlador/cable/backplane puede estar limitándolo.
Decisión: Arregla el enlace antes de juzgar el rendimiento de L2ARC.

Task 12: Measure whether reads shift from HDD to L2ARC (before/after)

cr0x@server:~$ zpool iostat -v tank 2 2
                              capacity     operations     bandwidth
pool                        alloc   free   read  write   read  write
--------------------------  -----  -----  -----  -----  -----  -----
tank                        12.3T  7.10T    420    150  38.0M  11.5M
  raidz2-0                  12.3T  7.10T    420    150  38.0M  11.5M
    sda                         -      -     70     26   6.0M   2.0M
    sdb                         -      -     71     25   6.1M   1.9M
    sdc                         -      -     70     26   6.0M   2.0M
    sdd                         -      -     69     25   5.9M   1.9M
    sde                         -      -     70     24   6.0M   1.8M
    sdf                         -      -     70     24   6.0M   1.8M
--------------------------  -----  -----  -----  -----  -----  -----

Qué significa: Si tu carga es similar, la caída de lecturas HDD de ~980 ops a ~420 ops sugiere que los aciertos en caché aumentaron (ARC y/o L2ARC).
Decisión: Correlaciona con la latencia de la aplicación. Si los usuarios lo notan, mantenlo. Si no, no declares victoria solo por contadores de almacenamiento.

Task 13: Check dataset properties that affect cache behavior

cr0x@server:~$ zfs get -o name,property,value -s local,default recordsize,primarycache,secondarycache,compression tank/vmstore
NAME          PROPERTY        VALUE
tank/vmstore  recordsize      128K
tank/vmstore  primarycache    all
tank/vmstore  secondarycache  all
tank/vmstore  compression     lz4

Qué significa: secondarycache=all permite que L2ARC cachee tanto datos como metadatos (sujeto a la política de ZFS).
Decisión: Para algunas cargas, poner secondarycache=metadata puede reducir escrituras en SSD manteniendo la «agilidad» en búsquedas de archivos.

Task 14: Restrict what goes into L2ARC for a noisy dataset

cr0x@server:~$ sudo zfs set secondarycache=metadata tank/backups
cr0x@server:~$ zfs get -o name,property,value secondarycache tank/backups
NAME          PROPERTY        VALUE
tank/backups  secondarycache  metadata

Qué significa: El dataset de backups dejará de contaminar L2ARC con datos masivos; los metadatos aún pueden cachearse.
Decisión: Usa esto cuando un dataset «frío» esté churnando L2ARC y expulsando bloques útiles para cargas interactivas.

Task 15: Remove an L2ARC device (for rollback)

cr0x@server:~$ sudo zpool remove tank ata-SAMSUNG_SSD_870_EVO_1TB_S6PNNX0R123456A
cr0x@server:~$ zpool status tank
  pool: tank
 state: ONLINE
config:

        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          raidz2-0  ONLINE       0     0     0
            sda     ONLINE       0     0     0
            sdb     ONLINE       0     0     0
            sdc     ONLINE       0     0     0
            sdd     ONLINE       0     0     0
            sde     ONLINE       0     0     0
            sdf     ONLINE       0     0     0

Qué significa: El dispositivo de caché se ha eliminado limpiamente.
Decisión: Si L2ARC no mejoró la latencia durante la ventana real de carga, quítalo y deja de pagar el impuesto operativo.

Tres mini-historias corporativas del mundo real

1) Incidente causado por una suposición errónea: “SSD de caché significa todo más rápido”

Una compañía mediana operaba un clúster NFS basado en ZFS para directorios home y artefactos de CI. La capacidad era un RAIDZ2 de HDD grandes.
Los desarrolladores se quejaban de «lentitud aleatoria», especialmente durante grandes builds y cuando los runners tiraban artefactos.

Un ingeniero bienintencionado añadió un SSD SATA de consumo como L2ARC en cada nodo. Nadie midió; solo esperaron aplausos.
Lo que consiguieron fue un incidente en cámara lenta: tras unos días, los SSD empezaron a mostrar latencias aumentadas y reinicios ocasionales.
Los builds se volvieron más lentos y los clientes NFS empezaron a hacer timeouts intermitentes, que parecían un problema de red hasta que no lo eran.

La suposición errónea fue que la carga era cacheable por lectura. No lo era. Las descargas de artefactos eran a menudo lecturas únicas; los builds escribían salidas nuevas constantemente;
el conjunto «caliente» cambiaba cada hora. L2ARC se alimentaba con bloques que nunca se volvían a leer, convirtiendo el SSD en un sumidero de escrituras.

La solución fue poco glamorosa: quitar L2ARC, añadir RAM y separar el almacén de artefactos a un conjunto mirror vdev dimensionado para IOPS, no para capacidad.
El equipo también configuró secondarycache=metadata para el dataset de backups que estaba contaminando ARC/L2ARC durante trabajos nocturnos.

Después, el rendimiento mejoró en la única forma que importa: menos alertas, menos quejas y gráficos que dejaron de parecer sismología.

2) Optimización que salió mal: “Hagamos L2ARC enorme”

Una plataforma analítica interna corría en ZFS. El equipo de almacenamiento tenía RAM decente y notó misses en ARC durante la avalancha matutina de dashboards.
Añadieron un par de SSD SATA grandes como L2ARC y decidieron «ir a lo grande» porque los SSD eran baratos por GB.

Los números iniciales parecían prometedores: el tamaño de L2ARC subió a terabytes y los contadores de aciertos aumentaron. Pero la latencia de usuario no mejoró mucho.
Peor aún, aparecieron parones periódicos—pausas cortas y agudas que parecían fallos de aplicación hasta que se alinearon con métricas de almacenamiento.

El contratiempo vino por el overhead en memoria y el churn. La máquina ahora cargaba una huella de índice L2ARC mucho mayor en RAM, reduciendo el ARC efectivo.
Bajo carga pico, la expulsión en ARC aumentó, la alimentación a L2ARC subió y los SSD SATA alcanzaron límites de escritura sostenida.
La capa de caché empezó a comportarse como un acceso congestionado: todo se ralentizó porque demasiado intentaba entrar.

El equipo corrigió reduciendo ambiciones: limitaron qué datasets podían usar L2ARC (otra vez, secondarycache fue la palanca),
y dejaron de tratar L2ARC como sustituto barato de un mejor layout de vdevs.
Más tarde migraron los datasets de dashboards con muchas lecturas a espejos NVMe y dejaron los SATA para roles menos sensibles a latencia.

La lección fue dolorosa pero útil: «caché más grande» no es una estrategia de rendimiento a menos que tu carga sea realmente amigable con caché y tu sistema tenga presupuesto de memoria.

3) Práctica aburrida pero correcta que salvó el día: mediciones base y rollback

Una empresa regulada tenía una plataforma ZFS que soportaba varios servicios internos. Querían mejorar lecturas para un datastore VM en mirrors HDD.
Los tiempos de procurement eran lentos, así que el ingeniero propuso un L2ARC en SSD SATA como impulso temporal.

Antes de tocar producción, hicieron tres cosas aburridas: capturaron la latencia de base durante pico, registraron estadísticas ARC/L2ARC (no había L2ARC aún)
y escribieron un plan de rollback incluyendo el comando exacto zpool remove y una ventana de cambio.
También pre-chequearon atributos SMART y confirmaron la velocidad SATA negociada en el controlador que planeaban usar.

El cambio se hizo limpio. Durante dos semanas, las métricas mostraron un cambio claro: las ops de lectura HDD bajaron durante tormentas de arranque y la p95 de la aplicación mejoró de forma modesta pero consistente.
Luego apareció un bug de firmware en el modelo de SSD (no catastrófico, solo molesto) y el dispositivo desaparecía ocasionalmente bajo carga de escritura pesada.

Como tenían baseline, pudieron cuantificar la regresión, desactivar L2ARC rápido y volver al estado conocido sin debates ni juegos de culpables.
Más tarde reemplazaron el modelo de SSD por uno con mejor comportamiento sostenido e reintrodujeron L2ARC con confianza.

Nadie recibió un trofeo por «mejor higiene operativa». Pero nadie recibió un pager por la noche tampoco, que es el verdadero premio.

Errores comunes: síntomas → causa raíz → arreglo

1) Síntoma: la ratio de aciertos de L2ARC está cerca de cero tras días

Causa raíz: La carga no re-lee bloques, o los datasets no son elegibles para L2ARC por ajustes de secondarycache, o la caché se contamina por cargas de streaming.

Arreglo: Valida el comportamiento de re-lectura; pon secondarycache=metadata en datasets de streaming; considera quitar L2ARC y añadir RAM o vdevs en su lugar.

2) Síntoma: el sistema se siente más lento tras añadir L2ARC

Causa raíz: Presión de memoria (ARC reducido por overhead de metadatos de L2ARC), además de I/O de escritura adicional por la alimentación de caché en SSD.

Arreglo: Añade RAM o reduce cargas competidoras; limita ARC apropiadamente; restringe uso de L2ARC por dataset; considera L2ARC más pequeño o ninguno.

3) Síntoma: el dispositivo SSD muestra mucho desgaste rápidamente

Causa raíz: Alta tasa de alimentación L2ARC por churn en ARC; resistencia del SATA de consumo no dimensionada para ello.

Arreglo: Elige un SSD de mayor resistencia; reduce la alimentación restringiendo datasets; prioriza crecimiento de ARC; considera NVMe para rendimiento sostenido si lo necesitas.

4) Síntoma: parones de I/O periódicos durante picos

Causa raíz: Estrangulamiento del SSD SATA o controlador SATA saturado; la alimentación de caché compite con lecturas; comportamiento del firmware del SSD bajo escrituras sostenidas.

Arreglo: Revisa comportamiento en escrituras sostenidas; verifica velocidad de enlace; reparte caché entre dispositivos/controladores; elige SSDs con escrituras sostenidas estables y PLP.

5) Síntoma: grandes números sintéticos en benchmarks, sin mejora real

Causa raíz: El benchmark cabe en ARC o usa un patrón cache-friendly distinto al de producción; la ventana de medición ignora calentamiento y localidad real de acceso.

Arreglo: Mide durante el pico real; limpia artefactos de prueba; evalúa latencia end-to-end y reducción de ops de disco, no solo contadores de caché.

6) Síntoma: tras reinicio, el rendimiento es malo «hasta que deja de serlo»

Causa raíz: Calentamiento de L2ARC; contenidos de caché no inmediatos o no reconstruidos; ARC en frío.

Arreglo: Planifica reinicios en ventanas de baja carga; precarga caches con datasets comunes si es práctico; no juzgues la efectividad de L2ARC inmediatamente después de un reinicio.

Listas de verificación / plan paso a paso

Lista de decisión: ¿deberías añadir L2ARC SATA?

1. ¿El problema es mayoritariamente latencia de lectura? Si no, para. L2ARC no arregla problemas limitados por escrituras.
2. ¿Los discos están saturados durante la ventana de dolor? Si no, puede que estés limitado por CPU/red/aplicación.
3. ¿La tasa de misses de ARC es significativamente alta? Si ARC ya acierta de forma dominante, L2ARC probablemente no moverá la aguja.
4. ¿La carga re-lee datos? Si no, L2ARC será consumo de resistencia.
5. ¿Tienes margen de RAM? Si estás haciendo swap, no añadas L2ARC.
6. ¿Puedes medir antes/después? Si no puedes, estás haciendo teatro de rendimiento.

Plan de implementación (seguro, reversible)

1. Registra baseline: zpool iostat, iostat -x, arcstat durante el pico.
2. Elige SSD: prioriza resistencia y escrituras sostenidas estables sobre marketing.
3. Verifica la ruta de hardware: controlador correcto, negociado a 6.0 Gb/s, refrigeración decente.
4. Añade L2ARC con zpool add tank cache ....
5. Espera el calentamiento bajo carga real; no lo evalúes tras 10 minutos.
6. Compara: ops/latencia de lectura de disco y latencia p95/p99 de la aplicación.
7. Si ayuda, restringe datasets ruidosos con secondarycache.
8. Si no ayuda, quítalo con zpool remove y sigue adelante.

Lista operativa (para que no sea sorpresa)

• Monitoriza desgaste de SSD mensualmente (SMART).
• Alerta si el dispositivo de caché desaparece o hay errores de enlace (errores CRC).
• Documenta que la caché es desechable para que nadie entre en pánico durante el reemplazo.
• Vuelve a probar rendimiento tras cambios importantes en la carga (nueva versión de app, nuevos patrones de consulta, nueva flota de VM).

Preguntas frecuentes

1) ¿L2ARC acelera las escrituras?

No. L2ARC es una caché de lectura. Para latencia de escrituras síncronas mira SLOG, y aun así trata sobre logging, no en acelerar todas las escrituras.

2) ¿Debería añadir L2ARC antes que RAM?

Casi nunca. La RAM incrementa ARC sin añadir latencia de dispositivo, escrituras de alimentación o superficies de fallo extra. Si puedes añadir RAM, hazlo primero.

3) ¿Un SSD SATA de consumo es «suficiente» para L2ARC?

A veces. Si tu tasa de alimentación es moderada y la carga es lectora con re-lecturas reales, puede bastar. Si la alimentación es intensa, los SSD de consumo tienden a desgastarse y estrangularse.

4) ¿Cómo sé si mi carga re-lee datos?

Observa si los aciertos en caché aumentan con el tiempo y si las operaciones de lectura en HDD bajan mientras la carga se mantiene similar. Si L2ARC sigue escribiendo pero los aciertos quedan bajos, no es amigable con re-lecturas.

5) ¿L2ARC persiste tras reinicio?

El contenido del SSD puede permanecer, pero la utilidad depende de si ZFS reconstruye el índice y cómo esté configurada tu plataforma. Prácticamente, planifica un periodo de calentamiento tras reinicio.

6) ¿Debo espejar dispositivos L2ARC?

Normalmente no. L2ARC es desechable; si falla el dispositivo, pierdes caché, no datos. Si perder caché causa caídas de rendimiento inaceptables, la solución real es más ARC o almacenamiento primario más rápido.

7) ¿Por qué mi L2ARC muestra actividad pero los usuarios no notan mejora?

Puede que estés acertando metadatos o bloques pequeños mientras el dolor real está en otro lado (CPU, red, escrituras síncronas), o que los aciertos sean en lecturas no críticas. Mide latencia de aplicación y ops de disco, no solo contadores de caché.

8) ¿Puedo restringir qué datasets usan L2ARC?

Sí. Usa secondarycache por dataset (por ejemplo, metadata para datasets de streaming/backup) para evitar contaminar L2ARC con datos fríos y masivos.

9) ¿SATA SSD o NVMe para L2ARC?

NVMe gana en latencia y paralelismo. SATA aún puede ayudar cuando reemplazas misses de HDD por aciertos «suficientemente buenos» en SSD a bajo coste, y tu carga no es ultra-sensible a latencia.

10) ¿Cuál es la alternativa a L2ARC para cargas de archivos pequeños?

Un vdev especial (con redundancia) puede almacenar metadatos y bloques pequeños en SSD, entregando a menudo ganancias mayores que L2ARC para cargas dominadas por metadatos. Pero no es desechable; diseñado así como almacenamiento real.

Siguientes pasos que puedes hacer hoy

1. Ejecuta la guía rápida de diagnóstico durante el pico y anota si estás limitado por lectura, escritura, CPU o memoria.
2. Captura baselines: iostat -x, zpool iostat -v, arcstat al menos 10 minutos durante la ventana de dolor.
3. Si eres candidato, añade un SSD SATA como L2ARC con un plan claro de rollback y una ventana de medición lo bastante larga para el calentamiento.
4. Hazlo aburrido: monitoriza desgaste SMART, alerta sobre errores de dispositivo y mantén intencionales las configuraciones de caché por dataset.
5. Si L2ARC no mejora la latencia de usuario, quítalo. Invierte tiempo y dinero en ARC (RAM), diseño de vdevs o mover el dataset caliente a almacenamiento más rápido.

El resultado más limpio no es «añadimos caché». Es «probamos cuál era el cuello de botella, lo arreglamos y ahora nadie habla de almacenamiento en las reuniones».