🌐 También en: English · Deutsch · Français
Uno cortito, y consecuencia directa del artículo sobre snapshots. Al añadir snapshots diarios metí en este NAS algo que antes no existía: una cosa que crece sola, en silencio, para siempre, sin que nadie se lo pida. Así que me puse a buscar qué me avisaría cuando el pool empezara a llenarse. La respuesta fue un poco bochornosa.🔍 ZED opina de todo, menos de esto
ZED está en marcha. Está configurado. Justo eso fue lo que arreglé en el último anexo, y el arreglo aguanta:$ systemctl is-active zed
active
$ grep ZED_EMAIL_ADDR /etc/zfs/zed.d/zed.rc
ZED_EMAIL_ADDR="you@example.com"🧊 Por qué «pues borra algo» ya no es la salida de emergencia que era
En ext4, un disco lleno es un fastidio. En ZFS es peor, por dos motivos que se agravan mutuamente. Primero, el rendimiento de escritura cae de forma notable una vez que pasas de aproximadamente el 80 %: el asignador tiene que esforzarse más para encontrar espacio contiguo, y se nota. Segundo, y este es el que pilla a la gente: borrar archivos puede fallar en un pool completamente lleno, porque borrar ya es en sí una escritura. Eliminar un archivo implica actualizar metadatos, y con copy-on-write actualizar metadatos implica asignar un bloque. Sin bloques libres, no hay borrado. Ahora pon los snapshots encima. Como conté en el artículo sobre snapshots, borrar un archivo al que todavía hace referencia un snapshot no libera exactamente nada:storage/demo USED: 200M REFER: 128KREFER es lo que hay en el directorio activo: prácticamente nada. USED es lo que el dataset ocupa de verdad, porque un snapshot está reteniendo los bloques. Así que la jugada de rescate instintiva —liberar espacio borrando cosas— no te lleva a ninguna parte en un dataset con snapshots, y puede que ni siquiera se ejecute en un pool realmente lleno. Una combinación que más vale no descubrir en directo.🛠️ Cinco líneas y un timer
El check en sí no tiene nada de especial, y de eso se trata:#!/bin/bash
# /usr/local/sbin/zfs-capacity-check.sh
set -euo pipefail
WARN="${1:-80}"
RECIPIENT="$(grep -hE '^ZED_EMAIL_ADDR=' /etc/zfs/zed.d/zed.rc 2>/dev/null
\
| head -1 | cut -d= -f2- | tr -d '"' | xargs)"
[ -n "$RECIPIENT" ] || exit 0
problems=""
while read -r pool cap; do
num="${cap%\%}"
[ "$num" -ge "$WARN" ] || continue
problems="${problems}Pool '${pool}' is ${cap} full (threshold: ${WARN}%).
"
done < <(zpool list -H -o name,capacity)
[ -n "$problems" ] || exit 0
# ... assemble report, pipe into mail ...zed.rc en lugar de estar escrito a fuego. En esta máquina ya hay exactamente un sitio donde se configura «a quién se avisa cuando el almacenamiento hace de las suyas», y añadir un segundo es la manera perfecta de que ambos se desincronicen sin hacer ruido dentro de seis meses. Y el correo no se limita a decir «el pool está lleno». Enumera los snapshots más grandes, porque en una máquina ZFS con snapshots automáticos esa es, con muchísima diferencia, la respuesta a «¿dónde se ha ido mi espacio?», y el mensaje que llega a las 3 de la madrugada debería traer la respuesta, no solo la pregunta. El timer tiene la misma forma que los de los snapshots: diario, Persistent=true, retardo aleatorio.✅ Probar el chisme que se supone que me avisa
El último anexo terminó con un componente cuyo único trabajo era dar la alarma y que fallaba en silencio. No pienso tropezar dos veces con la misma piedra. Así que, en lugar de fiarme de un check que informa correctamente de «todo en orden» con un pool al 49 %, bajé el umbral hasta que no le quedó más remedio que dispararse:$ /usr/local/sbin/zfs-capacity-check.sh 40
$ tail -2 /var/log/msmtp.log
Sep 02 21:19:09 host=smtp.strato.de ... recipients=you@example.com
smtpstatus=250 exitcode=EX_OK
Sep 11 14:47:14 host=smtp.strato.de ... recipients=you@example.com
mailsize=861 smtpstatus=250 exitcode=EX_OK250, EX_OK. Toda la cadena funciona: script, mail, msmtp, Strato, entregado. Y fíjate en la línea de arriba. 2 de septiembre: es el mensaje de prueba de ZED del anexo anterior, ahí mismo, en el mismo log. Dos vías de alerta, con nueve días de diferencia, ambas verificadas de la misma forma y por el mismo motivo.
