Ediciones mineras: las mejores y peores ideas que entregó la industria

Qué son realmente las “ediciones mineras” (y por qué existen)

“Edición minera” no es una sola clase de producto. Es un paraguas de marketing sobre un conjunto de decisiones de diseño hechas cuando el comprador es un minero: sensible al precio, obsesionado por el rendimiento por vatio y que no busca un contrato de servicio de cinco años. Las ediciones mineras aparecen como GPUs con menos salidas de vídeo, placas base con más ranuras PCIe, fuentes diseñadas para carga continua y—menos comúnmente—dispositivos de almacenamiento vendidos como “optimizados” para cargas de escritura intensivas.

Dos cosas hacen a las ediciones mineras interesantes desde la operación:

• Ajuste para una sola carga de trabajo: Un rig de minería puede ser estable y aun así ser una máquina pésima para usos generales. Puedes eliminar funciones, reducir el alcance de validación y aun así “pasar” si la única carga es hasheo.
• Inversión del ciclo de vida: El hardware retail está diseñado para un ciclo de vida de consumidor (uso intermitente, mucho tiempo inactivo, juego ocasional). El hardware minero se usa como un pequeño nodo de centro de datos: alta utilización, calor constante, vibración constante y consumo eléctrico constante. Luego se revende a gente que asume que “usado” significa “ligeramente usado”.

Las ediciones mineras fueron una respuesta racional a picos de demanda. Los fabricantes vieron pedidos masivos previsibles y crearon SKUs más baratos de fabricar y más fáciles de asignar. El problema es lo que pasa después: esas SKUs terminan en entornos con suposiciones distintas—tu entorno.

Un encuadre útil: las ediciones mineras no son “malas.” Son estrechas. La estrechez está bien en un sistema controlado con los controles adecuados. La estrechez es una mina en un parque de flotas mixtas donde tu monitorización está construida alrededor de la idea de que “un disco es un disco”.

Hechos y contexto histórico (las partes que la gente olvida)

1. La demanda minera remodeló repetidamente las cadenas de suministro de GPU. Grandes escaseces a finales de los 2010 y principios de los 2020 empujaron a los fabricantes a crear SKUs específicas para minería para proteger las líneas de gamer y workstation—al menos en el papel.
2. Algunas GPUs mineras se enviaron con menos o sin salidas de vídeo. Eso no fue solo ahorro de costes; redujo puntos de fallo y desincentivó la reventa al canal gamer.
3. El “firmware minero” no siempre fue sobre velocidad. En varios casos, el firmware apuntaba a límites de potencia, curvas de ventilador o estabilidad a relojes fijos en lugar del rendimiento pico.
4. Chia y otras fases de proof-of-space convirtieron brevemente los SSD en consumibles. Escrituras sostenidas intensivas agotaron la endurance de la NAND de consumo lo suficientemente rápido como para que la “salud del disco” fuera un argumento de reventa.
5. Las características de disco empresarial importan más bajo carga continua. Cosas como TLER/ERC (límites de recuperación de error) y tolerancia a vibración son la diferencia entre “lento” y “colapso del pool” bajo presión de reconstrucción RAID/ZFS.
6. Los mercados de refurb crecieron dramáticamente tras las caídas mineras. Eso creó un ecosistema secundario de reetiquetado, resets SMART (sí, sucede) y dispositivos “recertificados” con procedencia borrosa.
7. Los patrones de ciclado térmico cambiaron. El hardware de consumo suele morir por ciclos repetidos de calentamiento/enfriamiento; el hardware minero muere por exposición sostenida al calor y desgaste de ventiladores.
8. Los términos de garantía a menudo eran deliberadamente poco atractivos. Períodos de garantía cortos o cobertura limitada no son señal de incompetencia del fabricante; son un modelo de precios alineado con un comprador que espera amortizar rápido.

Las mejores ideas que trajeron las ediciones mineras

1) Orientación honesta a la carga de trabajo (cuando realmente lo era)

Los mejores productos de “edición minera” admitían lo que eran: hardware simplificado optimizado para operación sostenida. Quitar salidas de vídeo en GPUs no era malicioso. Reducía el coste del BOM, reducía la probabilidad de daño por ESD o conectores y simplificaba el soporte. Si estás desplegando aceleradores solo de cómputo, los DisplayPort son mayormente decoración y un fallo de campo sorprendentemente común.

Dónde funciona en producción: nodos construidos para propósito. CI runners que hacen cómputo GPU. Granjas de render. Pods de entrenamiento ML donde la salida es un problema de red, no de DisplayPort.

Decisión: si el SKU es realmente solo de cómputo, trátalo como tal. No lo mezcles en una flota de workstation y luego te quejes de que no es una workstation.

2) Eficiencia energética como característica principal

Los mineros forzaron a fabricantes y comunidades a preocuparse por rendimiento-por-vatio. Esa obsesión derivó en mejores prácticas de undervolting, telemetría de potencia más accesible y una cultura de “hacerlo estable, no heroico”. En términos SRE: la cultura minera normalizó ejecutar hardware en un punto conservador de la curva—menos potencia, menos calor, menos fallos.

No es glamuroso. Es efectivo. Temperaturas de unión más bajas y menor estrés en los VRM te compran margen operativo, especialmente en racks densos o entornos con refrigeración marginal.

3) Mayor densidad de ranuras y conectividad sencilla

Las placas y risers mineros fueron un desastre al principio, pero la presión de “más lanes, más ranuras” produjo diseños interesantes. Incluso fuera de la minería, hay valor en placas que priorizan expandibilidad y topología PCIe directa.

La buena versión de esta idea es “simple e inspeccionable.” Una placa con compartición de lanes clara y menos características decorativas puede ser más fácil de operar que una placa gaming llena de funciones.

4) Tratar los ventiladores como consumibles (finalmente)

Los rigs de minería enseñaron algo obvio: los ventiladores fallan. Fallan mecánicamente, se obstruyen y se vuelven ruidosos antes de morir. Si un fabricante diseña para reemplazo fácil de ventiladores—o si tu práctica de operaciones asume reemplazo de ventiladores—la disponibilidad mejora.

En almacenamiento, la analogía es reemplazar pestillos de bandejas, limpiar filtros y tratar el flujo de aire como parte del sistema. Las ediciones mineras no inventaron el flujo de aire, pero lo hicieron difícil de ignorar.

5) Claridad económica: amortización corta impulsa planificación honesta

La economía minera es brutal e inmediata. Esa mentalidad puede ser saludable en TI: deja de asumir que el hardware dura para siempre y empieza a modelar rendimiento y fallos en función de utilización y ambiente.

Cuando un equipo aprende esto, deja de comprar lo más barato que “funciona” y empieza a comprar lo más barato que opera. Esas son partidas diferentes.

Las peores ideas que trajeron las ediciones mineras

1) Eliminar funciones que no eran “agradables de tener”

Las malas ediciones mineras no solo quitaron puertos. Quitar resiliencia. En GPUs eso podría significar VRM de peor calidad, ventiladores de menor calidad o placas ajustadas a un solo punto de voltaje/frecuencia con poco margen. En almacenamiento, el equivalente es firmware que se comporta de forma extraña bajo recuperación de errores o estrés térmico, o dispositivos que carecen de reporte predecible.

Las cargas mineras son extrañamente tolerantes a ciertos fallos. Una GPU puede lanzar errores de cómputo ocasionales y un minero puede no notarlo—o aceptarlo como una pequeña pérdida de eficiencia. Tu carga de trabajo de producción puede no ser tan indulgente.

2) La garantía como pensamiento posterior (o como no-función deliberada)

Garantías cortas y términos RMA limitados no son solo “molestos.” Cambian tu modelo de confiabilidad. Si tu flota asume que puedes RMA un componente que falla rápidamente, las ediciones mineras rompen esa suposición. Ahora tu estrategia de repuestos es la garantía.

Si compras ediciones mineras sin un plan de repuestos, no estás siendo frugal. Estás externalizando tu respuesta a incidentes a la suerte.

3) Diseño térmico que asume bastidores de aire abierto

Muchos rigs mineros funcionan en bastidores abiertos con mucho aire ambiente y tolerancia al ruido. Pon ese mismo hardware en un chasis con expectativas de flujo frontal-trasero y obtienes puntos calientes, recirculación y throttling. El dispositivo no es “malo.” La integración es mala.

Y cuando las GPUs hacen throttling, no siempre lo hacen de forma elegante. Verás jitter, picos de latencia y el peor tipo de rendimiento: rendimiento que parece correcto hasta el momento crítico.

4) “Reacondicionado” como término de marketing, no como proceso

Aquí es donde los ingenieros de almacenamiento se llevan las manos a la cabeza. Los mercados post-minería crearon incentivos para un reacondicionado descuidado: reetiquetar discos, cambiar PCBs, limpiar logs, mezclar lotes y vender unidades “probadas” que se probaron lo justo para arrancar.

La mayoría de esto no es malicioso. Es economía. Probar cuesta dinero y el comprador va detrás del precio.

Broma #1: Comprar un “SSD minero ligeramente usado” es como adoptar un caballo de carreras retirado para fiestas infantiles. A veces está bien. A veces patea tu cerca.

5) Sobreoptimizar narrativas de resistencia a escrituras secuenciales

Algunos productos de almacenamiento “optimizados para minería” se apoyaron demasiado en afirmaciones de endurance que no coincidían con cargas mixtas del mundo real. Los números de endurance pueden ser técnicamente correctos y aun así engañosos. Las escrituras no son todas iguales: profundidad de cola, localidad, amplificación de escritura, comportamiento de garbage collection y temperatura importan.

Para los operadores, el modo de fallo es predecible: compras discos “alta endurance”, los pones bajo un patrón de escritura distinto al optimizado y ves cómo la latencia se convierte en una sierra.

Modos de fallo: qué se rompe primero y cómo se ve en producción

GPUs mineras: la muerte lenta de la refrigeración y la entrega de energía

Las GPUs mineras viven calentadas. Los fallos comunes no son misteriosos:

• Desgaste del ventilador: los rodamientos se degradan, las RPM caen y la GPU alcanza límites térmicos, bajando relojes.
• Degradación de pasta/tapas térmicas: las temperaturas en las uniones de memoria suben primero, especialmente en placas de era GDDR6X.
• Estrés en VRM: la carga sostenida más el calor envejecen componentes; la inestabilidad aparece como reinicios de driver, errores ECC (si son soportados) o colgaduras duras.

En cargas mixtas, esto aparece como fallos intermitentes en jobs y jitter de rendimiento que parecen “software” hasta que lo correlacionas con telemetría de temperatura y potencia.

SSDs mineros: la endurance es solo la mitad de la historia

Las gráficas de plotting (proof-of-space) pueden consumir NAND rápidamente. Un disco usado puede seguir pareciendo “saludable” si solo miras un valor SMART porcentual. Mientras tanto, puede tener:

• Indicadores de desgaste alto y bloques de reserva reducidos, llevando a fallos repentinos en acantilado.
• Patrones de throttling térmico que matan la latencia tail.
• Comportamiento de firmware inconsistente bajo escrituras sostenidas en un chasis con mal flujo de aire.

Los operadores deberían tratar los SSD usados de minería como sospechosos a menos que puedas validar indicadores de desgaste y correr pruebas de escritura sostenida a temperatura operativa.

HDDs mineros: no son comunes, pero cuando pasan es feo

Los HDDs no suelen ser “dispositivos mineros” para proof-of-work, pero proof-of-space creó casos donde se usaron y revendieron grandes arrays HDD. A los HDDs les disgusta la vibración y el calor. Pon suficientes discos juntos sin tolerancia a vibración y obtienes:

• Errores de lectura bajo carga que disparan recuperaciones largas.
• Timeouts en RAID/ZFS que parecen problemas de controlador.
• Tormentas de reconstrucción: un disco marginal causa una reconstrucción; la reconstrucción estresa al resto; ahora estás en un torneo de eliminación de discos.

Una cita para mantenerte honesto

Werner Vogels (CTO de Amazon) dijo: “Everything fails, all the time.”

Guía rápida de diagnóstico: qué revisar primero/segundo/tercero para encontrar el cuello de botella rápidamente

Cuando un dispositivo de “edición minera” rinde mal o falla, la gente tiende a discutir sobre calidad. No lo hagas. Diagnostica como siempre: observa, aisla, confirma.

Primero: confirma que es hardware (no scheduler, no red, no config)

• Revisa carga a nivel host, throttling y errores del kernel.
• Confirma que el problema sigue al dispositivo cuando se mueve (si es factible) o persiste tras reinicios (si es seguro).
• Busca eventos térmicos/eléctricos alrededor del momento del incidente.

Segundo: identifica el subsistema limitante (potencia, térmico, PCIe, medio, firmware)

• Potencia: undervolt, saturación de rieles PSU, caídas transitorias.
• Térmico: temperaturas sostenidas altas causando caídas de reloj o throttling del medio.
• PCIe: enlaces downtraining, errores AER, inestabilidad de riser.
• Medio: desgaste SMART, reallocaciones, reintentos de lectura, errores no corregibles.
• Firmware: timeouts extraños, manejo inconsistente de errores, telemetría ausente.

Tercero: decide si rehabilitar o poner en cuarentena

Algunos problemas son solucionables (ventiladores, pasta, flujo de aire, límites de potencia). Otros no lo son (desgaste NAND, degradación de cabezales, errores crónicos de PCIe). La decisión es económica y operativa:

• Si el dispositivo es no determinista, ponlo en cuarentena. Los fallos no deterministas desperdician tiempo de ingenieros y envenenan la confianza.
• Si el dispositivo falla bajo calor, arregla el flujo de aire y vuelve a probar. Si sigue fallando, cuarentena.
• Si SMART muestra degradación del medio, no negocies con ello. Reemplaza.

Tareas prácticas: comandos, salidas y decisiones

A continuación hay tareas prácticas que puedes ejecutar en hosts Linux. Cada una incluye un comando realista, salida de ejemplo y qué decisión tomar. No son “benchmarks por diversión.” Son herramientas de triage.

Task 1: Identify the exact device model and firmware

cr0x@server:~$ lsblk -d -o NAME,MODEL,SERIAL,FWREV,SIZE,ROTA,TYPE
NAME MODEL              SERIAL          FWREV  SIZE ROTA TYPE
sda  SAMSUNG_MZ7L31T9   S6Z1NX0R123456  GDC5  1.8T    0 disk
sdb  ST8000NM000A-2KE1  ZA1ABCDEF       SN03  7.3T    1 disk

Qué significa: Estás confirmando que no recibiste un modelo “vecino” con distinta endurance/comportamiento, y capturando la revisión de firmware por quirks conocidos.

Decisión: Si las revisiones de firmware varían mucho en un lote, para y estandariza antes del despliegue. Mezclar firmware en pools de almacenamiento es como conseguir timeouts inconsistentes.

Task 2: Check NVMe SMART / wear indicators

cr0x@server:~$ sudo nvme smart-log /dev/nvme0n1
Smart Log for NVME device:nvme0n1 namespace-id:ffffffff
critical_warning                    : 0x00
temperature                         : 62 C
available_spare                     : 98%
available_spare_threshold           : 10%
percentage_used                     : 41%
data_units_written                  : 189,345,221
media_errors                        : 0
num_err_log_entries                 : 12

Qué significa: percentage_used es definido por el fabricante pero en general correlaciona con consumo de endurance. Las entradas en el log de errores indican que el disco ha tenido incidencias aunque no se hayan convertido en media errors.

Decisión: Si percentage_used es alto para discos “nuevos”, trata el lote como usado. Si la temperatura es alta en reposo, arregla el flujo de aire antes de confiar en cualquier número de benchmark.

Task 3: Check SATA/SAS SMART basics

cr0x@server:~$ sudo smartctl -a /dev/sdb | sed -n '1,25p'
smartctl 7.4 2023-08-01 r5530 [x86_64-linux-6.5.0] (local build)
=== START OF INFORMATION SECTION ===
Device Model:     ST8000NM000A-2KE1
Serial Number:    ZA1ABCDEF
Firmware Version: SN03
User Capacity:    8,001,563,222,016 bytes [8.00 TB]
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

Qué significa: Verifica que SMART esté habilitado y accesible. Algunos controladores/bridges cuestionables mienten u ocultan SMART.

Decisión: Si SMART no está disponible, no lo despliegues en una flota que esperas operar. “Sin telemetría” es un olor a mala confiabilidad.

Task 4: Look for reallocated sectors and pending sectors (HDD)

cr0x@server:~$ sudo smartctl -A /dev/sdb | egrep 'Reallocated_Sector_Ct|Current_Pending_Sector|Offline_Uncorrectable'
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       0
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       2
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       1

Qué significa: Sectores pending y uncorrectable son señales rojas. Sectores reallocados pueden ser sobrevivibles si son estables, pero los pending son problemas activos.

Decisión: ¿Algún pending sector en un disco destinado a RAID/ZFS? Aislarlo. Las reconstrucciones convertirán medios marginales en armas.

Task 5: Check power-on hours (spot “new” that isn’t new)

cr0x@server:~$ sudo smartctl -A /dev/sdb | egrep 'Power_On_Hours|Start_Stop_Count'
  9 Power_On_Hours          0x0032   088   088   000    Old_age   Always       -       54781
  4 Start_Stop_Count        0x0032   099   099   000    Old_age   Always       -       32

Qué significa: 54k horas son años de operación continua. El conteo de arranques bajo sugiere “siempre encendido”, consistente con minería o uso en datacenter.

Decisión: No mezcles estos discos en pools de “discos nuevos”. Si debes usarlos, aísla por edad y planifica más repuestos.

Task 6: Run a short SMART self-test (quick triage)

cr0x@server:~$ sudo smartctl -t short /dev/sdb
Sending command: "Execute SMART Short self-test routine immediately in off-line mode".
Drive command "Execute SMART Short self-test routine immediately in off-line mode" successful.
Testing has begun.
Please wait 2 minutes for test to complete.

Qué significa: Una prueba corta detecta fallos obvios sin horas de downtime.

Decisión: Si las pruebas cortas fallan a la llegada, detén el despliegue. Eso no es “mortalidad infantil”; es tu proveedor diciéndote quién es.

Task 7: Read the self-test log (confirm failures)

cr0x@server:~$ sudo smartctl -l selftest /dev/sdb | tail -n +1
SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Short offline       Completed: read failure       10%     54782         123456789
# 2  Short offline       Completed without error       00%     54780         -

Qué significa: Un fallo de lectura con un LBA indica problemas reales de medio, no solo un cable suelto (aunque el cableado aún puede estar involucrado).

Decisión: Si los errores son repetibles, reemplaza el disco. Si los errores desaparecen tras reinsertar cables y mover puertos, sospecha del backplane/controlador.

Task 8: Detect PCIe link issues and AER errors (common with risers)

cr0x@server:~$ sudo dmesg -T | egrep -i 'AER|pcie.*error|nvme.*reset|link down' | tail -n 8
[Mon Jan 13 10:21:44 2026] pcieport 0000:00:1c.0: AER: Corrected error received: 0000:03:00.0
[Mon Jan 13 10:21:44 2026] nvme 0000:03:00.0: AER: can't recover (no error_detected callback)
[Mon Jan 13 10:21:45 2026] nvme nvme0: controller reset, status: 0x371
[Mon Jan 13 10:21:47 2026] nvme nvme0: I/O 123 QID 6 timeout, reset controller

Qué significa: Errores AER corregidos más resets NVMe suelen significar problemas de integridad de señal: risers, ranuras marginales o problemas de potencia.

Decisión: Si esto es un chasis derivado de minería con risers, quita el riser y vuelve a probar. Si los errores desaparecen, prohíbe ese modelo de riser en producción.

Task 9: Confirm NVMe thermal throttling events

cr0x@server:~$ sudo nvme get-feature /dev/nvme0n1 -f 0x10
get-feature:0x10 (Temperature Threshold), Current value:0x014b

Qué significa: La feature 0x10 se relaciona con umbrales de temperatura. Aún necesitas correlacionar con temperaturas reales y caídas de rendimiento.

Decisión: Si el dispositivo alcanza umbrales bajo carga normal, añade flujo de aire o disipadores. Si no puedes enfriarlo, no lo despliegues donde la latencia importe.

Task 10: Observe real-time I/O latency (storage bottleneck triage)

cr0x@server:~$ iostat -xz 1 3
Linux 6.5.0 (server) 	01/13/2026 	_x86_64_	(32 CPU)

avg-cpu:  %user %nice %system %iowait  %steal   %idle
          12.10  0.00    4.15    8.22    0.00   75.53

Device            r/s     w/s   rMB/s   wMB/s  avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
nvme0n1        120.0   980.0    12.5   110.2    246.0     8.40    7.90    2.10    8.60   0.38  42.0
sdb              3.0    60.0     0.1     4.2    142.0     2.10   48.2    4.20   50.1    4.10  28.5

Qué significa: await muestra la latencia de las solicitudes. Latencia de HDD alrededor de ~50ms bajo carga de escritura puede ser relativamente normal, pero se vuelve un problema si tu aplicación espera escrituras síncronas rápidas.

Decisión: Si un disco minado/usado muestra picos de latencia altos comparado con pares, retíralo del pool antes de que sea “el disco que arruina el día de todos”.

Task 11: Spot filesystem or block-layer timeouts

cr0x@server:~$ sudo journalctl -k --since "1 hour ago" | egrep -i 'timeout|reset|I/O error|blk_update_request' | tail -n 10
Jan 13 10:11:02 server kernel: blk_update_request: I/O error, dev sdb, sector 90234112 op 0x1:(WRITE) flags 0x0 phys_seg 8 prio class 0
Jan 13 10:11:02 server kernel: sd 2:0:0:0: [sdb] tag#19 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Jan 13 10:11:02 server kernel: sd 2:0:0:0: [sdb] Sense Key : Medium Error [current]

Qué significa: Medium errors son el disco admitiendo que no puede escribir/leer partes del medio de forma fiable.

Decisión: Reemplaza el disco. No lo “monitores de cerca.” La monitorización no repara dominios magnéticos.

Task 12: Check ZFS pool health and error counters

cr0x@server:~$ sudo zpool status -v
  pool: tank
 state: DEGRADED
status: One or more devices has experienced an error resulting in data corruption.
action: Replace the device and restore the pool from backup.
  scan: scrub repaired 0B in 01:22:14 with 2 errors on Mon Jan 13 09:55:01 2026
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        DEGRADED     0     0     0
          raidz1-0                  DEGRADED     0     0     0
            ata-ST8000NM000A_ZA1A   ONLINE       0     0     0
            ata-ST8000NM000A_ZA1B   ONLINE       0     0     0
            ata-ST8000NM000A_ZA1C   ONLINE       0     0     2
            ata-ST8000NM000A_ZA1D   ONLINE       0     0     0

errors: Permanent errors have been detected in the following files:
        /tank/db/pg_wal/0000000100000000000000A3

Qué significa: Los errores de checksum de ZFS significan que el disco (o la ruta) devolvió datos equivocados. Eso no es solo un disco lento; es daño en la integridad de datos.

Decisión: Reemplaza el dispositivo con errores CKSUM e investiga cableado/backplane. También restaura los datos afectados desde backup o replicación de mayor nivel.

Task 13: Check mdraid degradation and rebuild speed (Linux RAID)

cr0x@server:~$ cat /proc/mdstat
Personalities : [raid1] [raid10] [raid6] [raid5] [raid4]
md0 : active raid1 sda1[0] sdc1[1]
      976630336 blocks super 1.2 [2/2] [UU]

md1 : active raid5 sdb1[0] sdd1[1] sde1[2]
      15627534336 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [U_U]
      [>....................]  recovery =  4.2% (328463360/7813767168) finish=982.3min speed=127890K/sec

Qué significa: Un RAID5 degradado vive peligrosamente. La velocidad de reconstrucción te dice cuánto tiempo estarás expuesto.

Decisión: Si la velocidad de rebuild es anormalmente baja, busca un disco lento/errático. Reemplaza primero al disco rezagado; las tormentas de reconstrucción matan arrays.

Task 14: Validate sustained write behavior (catch throttling)

cr0x@server:~$ fio --name=steadywrite --filename=/dev/nvme0n1 --direct=1 --rw=write --bs=256k --iodepth=16 --numjobs=1 --runtime=60 --time_based=1 --group_reporting
steadywrite: (g=0): rw=write, bs=(R) 256KiB-256KiB, (W) 256KiB-256KiB, ioengine=psync, iodepth=16
fio-3.35
steadywrite: (groupid=0, jobs=1): err= 0: pid=18022: Mon Jan 13 10:33:29 2026
  write: IOPS=820, BW=205MiB/s (215MB/s)(12.0GiB/60001msec)
    clat (usec): min=350, max=88000, avg=2400.12, stdev=5200.31

Qué significa: Observa picos de latencia máxima (aquí, 88ms) y colapsos de ancho de banda con el tiempo. El throttling suele presentarse como acantilados periódicos de latencia.

Decisión: Si el rendimiento colapsa tras 30–60 segundos, no culpes a tu app. Arregla la refrigeración o evita este dispositivo para cargas de escritura sostenida.

Task 15: Check GPU clock throttling and temperatures

cr0x@server:~$ nvidia-smi --query-gpu=name,temperature.gpu,clocks.sm,clocks.mem,power.draw,pstate --format=csv
name, temperature.gpu, clocks.sm, clocks.mem, power.draw, pstate
NVIDIA GeForce RTX 3080, 86, 1110, 9251, 229.45, P2

Qué significa: Alta temp más reloj SM bajo a un determinado consumo sugiere limitación térmica o política de potencia conservadora. El P-state indica nivel de rendimiento.

Decisión: Si los relojes son inestables bajo carga, inspecciona ventiladores/pasta/pads. Si es una tarjeta minera, asume que requiere servicio antes de uso en producción.

Broma #2: El throttling térmico es la forma que tiene la GPU de decir: “No soy floja, estoy sindicada”.

Tres mini-historias corporativas (anonimizadas pero dolorosamente reales)

Mini-historia #1: El incidente causado por una suposición equivocada

Una empresa SaaS mediana compró muchos SSD “grado empresarial” a través de un reseller durante una crisis de suministro. Los discos llegaron en embalaje limpio, con etiquetas que parecían correctas y a un precio que hizo sentirse héroes al equipo de finanzas. Fueron desplegados en una capa de caché de base de datos—escritura intensiva, sensible a latencia, el lugar habitual donde pagas por fiabilidad comprando menos riesgo.

La suposición equivocada fue simple: “Si se identifica como el mismo modelo, se comporta como el mismo modelo.” Nadie verificó firmware, tipo de NAND o siquiera si los discos venían de un lote de fabricación consistente. El inventario parecía uniforme, así que se trató como uniforme en operaciones.

Tres semanas después, la latencia empezó a tener picos en horas pico. No latencia alta sostenida—picos. Ese tipo que convierte en timeouts visibles al usuario mientras tus dashboards los promedian con cierto decoro. Los logs del kernel mostraban reinicios NVMe ocasionales. El equipo culpó a una actualización de kernel reciente, la revirtió y vio… menos picos. Genial, salvo que fue coincidencia.

El problema real era el comportamiento térmico. Los discos pasaban en bancos de pruebas abiertos y a bajos ciclos de trabajo, pero en un chasis denso, bajo escrituras sostenidas, alcanzaban umbrales térmicos y empezaban throttling agresivo. Peor aún, no todos throttled igual; un subconjunto se reiniciaba bajo calor. La inspección posterior sugirió que el lote era una mezcla de variantes—algunas probablemente provenientes de uso intenso previo.

Arreglarlo no fue heroico. Estandarizaron firmware donde fue posible, mejoraron el flujo de aire y—lo más importante—dejaron de mezclar dispositivos no confiables en capas de latencia. Parte de los discos quedó relegada a cargas no críticas. El incidente se cerró con una lección que debería estar en cada formulario de compras: “mismo modelo” no es “mismo comportamiento”.

Mini-historia #2: La optimización que salió mal

Una compañía de procesamiento de medios corría transcodes intensivos en GPU. Compraron un lote de GPUs mineras usadas con descuento y decidieron “optimizarlas” para eficiencia. El plan: undervoltear agresivamente para reducir potencia y calor, luego meter más tarjetas por host. En el papel, parecía brillante. Menos watts, menos temps, mayor densidad, CFO feliz.

En staging pasó. Los trabajos completaron. El consumo bajó. Todos se felicitaron. El error fue tratar cargas de staging como representativas. Los transcodes en producción tenían mayor varianza: distintos codecs, resoluciones variadas, picos ocasionales en ancho de banda de memoria y un scheduler que creaba patrones de ráfaga.

Bajo esas ráfagas, las tarjetas undervoltadas empezaron a comportarse mal. No de forma instantánea. Intermitente. Algunos jobs fallaban con reinicios de driver, luego el host se recuperaba y volvía a fallar. Los ingenieros quemaron tiempo persiguiendo “contenedores malos”, “drivers defectuosos” y “condiciones de carrera en la pipeline”. Mientras tanto, el problema real era que el margen de undervolt era demasiado estrecho para la cola de la distribución de cargas.

La optimización salió mal operacionalmente: redujo el consumo medio pero aumentó la varianza y la tasa de fallos. La solución fue definir estabilidad como “sin reinicios bajo la peor carga posible a temperatura operativa”, no “pasa una prueba rápida”. Revirtieron el undervolt, aceptaron un poco más de consumo y redujeron la densidad de tarjetas por host. Menos tarjetas, menos incidentes, mayor throughput a lo largo de la semana.

Moraleja: optimizaciones que reducen margen son deuda. Puedes tomar el préstamo, pero producción cobrará intereses.

Mini-historia #3: La práctica aburrida pero correcta que salvó el día

Una fintech mantenía una práctica estricta para cualquier dispositivo de almacenamiento que entrara en un pool ZFS: pruebas de burn-in, baseline SMART y un calendario de scrubs ligado a alertas. No era glamuroso. Era el tipo de proceso que hace que la gente pregunte si eres “demasiado cauteloso”. También mantenían repuestos documentados y se negaban a desplegar discos que no pudieran proveer telemetría SMART fiable.

Durante una caída de mercado, compras propuso adquirir HDDs “reacondicionados de edición minera” para un gran clúster analítico. El equipo de almacenamiento no discutió filosóficamente. Aplicó proceso. Cada disco tuvo horas de encendido registradas, una prueba corta y larga de self-test y se colocó en una prueba de soak de lectura/escritura a la temperatura operativa objetivo.

El resultado fue incómodo pero útil: una porción no trivial de discos falló el burn-in o mostró atributos SMART preocupantes (pending sectors, fallos de lectura en self-test, logs de errores inestables). Porque el proceso existía, el equipo tuvo evidencia limpia para devolver discos y renegociar el lote.

El clúster se desplegó más tarde con un conjunto más pequeño de discos validados más una pool de repuestos mayor. Cuando un disco empezó a acumular errores de checksum meses después, los scrubs regulares lo detectaron pronto y el reemplazo fue rutinario en lugar de dramático. Sin all-hands. Sin impacto al cliente. Solo un ticket, un swap y cerrar.

Esta es la parte que nadie quiere oír: el mejor trabajo de fiabilidad es repetitivo. Les salvó porque convirtió las “ediciones mineras” de una apuesta a una variable controlada.

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

1) Síntoma: reinicios NVMe aleatorios bajo carga

Causa raíz: Problemas de integridad de señal PCIe (riser, ranura marginal), transientes de potencia o reinicios de controlador inducidos por temperatura.

Arreglo: Quita risers, reinsertar, bloquear la generación PCIe en BIOS si hace falta, mejorar refrigeración, verificar margen de PSU y volver a probar con carga sostenida.

2) Síntoma: quejas de “disco lento” durante reconstrucciones/scrubs

Causa raíz: Un disco débil causando reintentos; la reconstrucción RAID/ZFS amplifica la carga y empuja discos marginales al límite.

Arreglo: Identifica el outlier vía iostat/zpool status, reemplázalo temprano y evita mezclar discos antiguos/desconocidos con nuevos en el mismo vdev/array.

3) Síntoma: errores de checksum de ZFS, luego pánico

Causa raíz: Disco malo, cable/backplane defectuoso o controlador devolviendo datos corruptos.

Arreglo: Reemplaza el dispositivo/ruta afectada; ejecuta scrubs; restaura datos afectados. También audita cableado y firmware del HBA.

4) Síntoma: rendimiento GPU bien la primera hora y luego colapsa

Causa raíz: Throttling térmico o sobrecalentamiento de unión de memoria (pads/pasta degradada, ventiladores gastados).

Arreglo: Mantén refrigeración (ventiladores, pads, pasta), mejora flujo de aire del chasis y establece límites de potencia sensatos en lugar de perseguir relojes máximos.

5) Síntoma: discos “nuevos” muestran desgaste alto el primer día

Causa raíz: Hardware usado en empaques nuevos, manipulación de SMART o malentendido de métricas de desgaste del fabricante.

Arreglo: Valida horas de encendido y logs SMART al recibir; rechaza lotes inconsistentes; exige procedencia o compra en canales con devoluciones exigibles.

6) Síntoma: picos de latencia que no aparecen en promedios

Causa raíz: Throttling, garbage collection, recuperación de errores o pausas de firmware.

Arreglo: Mide latencia tail (p99/p999), ejecuta pruebas sostenidas y correlaciona con temperatura y logs del kernel. Evita usar estos dispositivos en capas de latencia.

7) Síntoma: logs del kernel muestran medium errors en HDD

Causa raíz: Degradación real del medio, a menudo acelerada por vibración y calor sostenido.

Arreglo: Reemplaza el disco inmediatamente, luego revisa vibración/flujo de aire del chasis y verifica que los vecinos no estén también degradándose.

8) Síntoma: dispositivos desaparecen y reaparecen al arrancar

Causa raíz: Inestabilidad de PSU, conectores flojos, rieles sobrecargados o problemas de backplane.

Arreglo: Audita el presupuesto de potencia, reemplaza cables sospechosos, valida el backplane y evita adaptadores/divisores baratos.

Listas de verificación / plan paso a paso

Checklist de recepción (antes de tocar producción)

1. Identidad de inventario: modelo, serial, firmware, capacidad, interfaz. Rechaza firmware mixto a menos que tengas un plan.
2. Validación de telemetría: asegúrate de que SMART/NVMe logs sean legibles sin magia del proveedor.
3. Chequeo de edad: registra Power_On_Hours / conteo de arranques; marca outliers.
4. Pruebas rápidas de salud: self-test corto a la llegada; rechaza fallos.
5. Burn-in soak: prueba sostenida de lectura/escritura a temperatura operativa realista.
6. Comportamiento térmico: confirma temperaturas bajo carga en el chasis que realmente usarás.
7. Aislamiento por lote: etiqueta dispositivos por lote y edad; evita mezclar en vdevs/arrays críticos.

Plan de despliegue (cómo no crear un incidente)

1. Empieza con cargas no críticas: trata el primer despliegue como canario.
2. Activa alertas en las señales correctas: errores I/O del kernel, resets NVMe, errores de checksum ZFS, throttling GPU.
3. Define SLOs de rendimiento: latencia p99 y tasa de error, no promedios.
4. Mantén repuestos en sitio: la garantía no es un plan operativo.
5. Documenta quirks conocidos: versiones de firmware, ajustes BIOS requeridos, límites de potencia, requisitos de refrigeración.
6. Decide una regla de cuarentena: define umbrales que disparen remoción automática.

Higiene operativa que paga la renta cada mes

1. Scrubs/parity checks regulares: detecta corrupción silenciosa temprano.
2. Tendencia de atributos SMART: vigila tasas de cambio, no solo valores absolutos.
3. Mantenimiento térmico: filtros, flujo de aire, ciclos de reemplazo de ventiladores.
4. Disciplina de firmware: actualizaciones controladas, no deriva aleatoria.

Preguntas frecuentes

1) ¿Los productos “edición minera” siempre son de menor calidad?

No. Están optimizados para un caso de uso más estrecho y normalmente para una vida útil esperada más corta. La calidad varía según fabricante y generación. Tu trabajo es validar, no estereotipar.

2) ¿Una GPU minera usada es automáticamente arriesgada para cómputo en producción?

Es más arriesgada que una GPU de workstation ligeramente usada porque probablemente corrió caliente y constante. El riesgo se puede gestionar: dar servicio a la refrigeración, validar estabilidad bajo peores cargas y monitorizar throttling y reinicios.

3) ¿Cuál es la mayor señal de alerta al comprar dispositivos de almacenamiento usados?

Telemetría inconsistente o ausente: SMART inaccesible, logs sospechosamente limpios o lotes con horas de encendido y firmware muy diferentes bajo el mismo “modelo”.

4) ¿Se puede falsificar o resetear datos SMART?

Sí, en algunos casos. No todos los atributos son fáciles de falsificar y no todos los fabricantes se comportan igual. Por eso el burn-in bajo carga y temperatura es parte del proceso, no un extra opcional.

5) ¿Debo mezclar discos minados/usados con discos nuevos en el mismo vdev RAID/ZFS?

Evítalo. Los arrays fallan cuando el miembro más débil se estresa y las reconstrucciones estresan a todos. Si debes usarlos, segrega por edad y procedencia y aumenta repuestos.

6) ¿Cuál es la forma más rápida de saber si un SSD va a throttlear?

Ejecuta una prueba de escritura sostenida de al menos 60 segundos (a menudo más), dentro del chasis real y observa throughput y latencia tail mientras monitorizas la temperatura.

7) Si una GPU es estable a un límite de potencia más bajo, ¿debería siempre limitarla?

A menudo sí, pero no busques el mínimo absoluto. Elige un límite conservador que preserve margen bajo cargas variables reales y temperaturas ambiente cambiantes.

8) ¿Por qué las ediciones mineras causan tantos problemas “intermitentes”?

Porque muchas están justo al borde: refrigeración marginal, entrega de potencia marginal o integridad de señal que funciona hasta que la temperatura sube o el bus se carga. Intermitente es lo que parece el edge-of-spec.

9) ¿Los discos empresariales siempre son más seguros que los de consumo en estas situaciones?

Usualmente son más seguros para arrays bajo carga continua por su comportamiento predecible de recuperación de errores y tolerancia a vibración. Pero “enterprise” en una etiqueta no garantiza procedencia; valida de todas formas.

10) ¿Qué hago si compras ya un lote?

No te enfades. Gatealo con burn-in, aísla a tiers no críticos primero y define umbrales de cuarentena estrictos. Haz visible y medible el riesgo.

Próximos pasos que puedes tomar esta semana

Las ediciones mineras no son un chiste; son una prueba de estrés de tu madurez operativa. Si tu entorno no puede tolerar procedencia desconocida, firmware mixto y márgenes térmicos estrechos, no tienes un problema de ediciones mineras. Tienes un problema de ingesta y validación.

Haz lo siguiente:

1. Escribe un estándar de recepción de una página para almacenamiento y GPUs: identidad, telemetría, burn-in y criterios de aceptación.
2. Define reglas de cuarentena que no requieran un debate a las 2 a.m.: pending sectors, errores de checksum, resets NVMe, eventos AER repetibles.
3. Instrumenta latencia tail y señales térmicas. Los promedios son donde los incidentes van a esconderse.
4. Segrega por lote y edad. Dominios de fallo homogéneos son más fáciles de razonar que sorpresas mixtas.
5. Mantén repuestos. Si la garantía es débil, los repuestos son tu garantía.

Cuando tratas las ediciones mineras como lo que son—hardware especializado con una historia de vida específica—puedes extraer valor real sin convertir tu rotación on-call en un archivo de folclore.