/ (/dev/sda1)
52 GB / 80 GB · 65%
/home (/dev/sdb1)
82 GB / 200 GB · 41%
/boot/efi (/dev/sda15)
317 MB / 1 GB · 31%
| Dispositivo | Tamaño | Modelo | Salud (SMART) | Temp. | Horas de uso | Sectores Realloc |
|---|---|---|---|---|---|---|
sda SSD |
80G | QEMU HARDDISK | OK | 33°C | 14,243 | 0 |
sdb SSD |
200G | Samsung SSD 870 | OK | 32°C | 9,230 | 0 |
Dos problemas de disco tumban servidores, y no se parecen en nada. El lento es una unidad que empieza a fallar, algo que SMART suele ver venir. El rápido es un sistema de archivos que se llena y arrastra consigo a los servicios: una base de datos que no puede escribir es una base de datos que se detiene.
Esta página cubre ambos: uso por sistema de archivos, atributos SMART por unidad y temperatura. Entre los atributos SMART, los que de verdad anticipan un fallo son el recuento de sectores reasignados, los sectores pendientes y los incorregibles fuera de línea; si alguno se aleja de cero, encargue un repuesto en lugar de esperar confirmación. La mayoría de los demás valores fluctúan sin importancia.
El agotamiento de inodos aparece por separado por lo desconcertante que resulta cuando ocurre: el disco informa de espacio libre, las escrituras fallan igualmente y nada en los sitios obvios lo explica. La causa es un directorio con cientos de miles de archivos diminutos — datos de sesión, cola de correo, una caché sin rotar — que consume la reserva fija de inodos del sistema de archivos sin apenas tocar su capacidad.
Hay una tercera desgracia de disco que no rompe nada y solo ralentiza: la unidad está tan ocupada que los procesos hacen cola ante ella. En cifras eso es el I/O wait, y rara vez sube por sí solo: casi siempre hay algo programado detrás, la copia nocturna, una reconstrucción de índices, un análisis completo de ClamAV sobre todo el sistema de archivos. Si el servidor se pone pesado siempre a la misma hora, busque un horario y no una avería.