Uso de fstrim en Linux para optimizar SSD

Inicio » Linux » Uso de fstrim en Linux para optimizar SSD

Usar correctamente fstrim en Linux se ha vuelto casi obligatorio si tienes un SSD y quieres que rinda como el primer día. Consulta cómo conocer la vida útil del SSD.

En las próximas líneas vamos a ver, paso a paso, qué es TRIM, qué papel juega fstrim y cómo dejarlo fino en cualquier GNU/Linux: requisitos, modos de uso (continuo vs periódico), configuración con systemd, LVM, dm-crypt, VDO y algunas buenas prácticas para alargar la vida del SSD. La idea es que cuando termines puedas auditar tu sistema, corregir lo que haga falta y quedarte tranquilo.

Qué es TRIM y por qué fstrim es tan importante en un SSD

Los SSD funcionan de forma muy distinta a los discos duros mecánicos. La memoria NAND se organiza en bloques y páginas: se escribe por páginas, pero se borra por bloques completos. No se puede sobrescribir directamente un bloque; primero hay que borrar y luego escribir, lo que introduce el famoso fenómeno de amplificación de escritura y, si no se gestiona bien, una caída de rendimiento bastante seria con el tiempo.

El sistema operativo, cuando borra un archivo, normalmente solo marca sus bloques como libres en el sistema de ficheros, pero el SSD no se entera de ese cambio. Desde su punto de vista, esos bloques siguen ocupados. Si nunca se informa al SSD de qué bloques ya no se usan, la controladora acaba trabajando casi todo el tiempo con páginas “medio llenas”, teniendo que copiar, borrar y reescribir para cada operación de escritura. De ahí vienen las gráficas de lectura llenas de dientes de sierra y velocidades cayendo al 20-30% de lo esperado.

TRIM es el mecanismo que soluciona este problema: es un comando que el sistema operativo envía al SSD para indicarle qué bloques ya no contienen datos válidos. Con esa información, la controladora puede reordenar internamente, borrar de antemano los bloques que sobran y mantener páginas libres listas para escribir de forma rápida.

En Linux, el comando de usuario que se usa para lanzar estas operaciones es fstrim. En pocas palabras, fstrim recorre un sistema de ficheros montado, identifica los bloques libres y envía comandos TRIM (discard) hacia abajo. Esto puede hacerse en tiempo real (cada borrado) o de forma periódica (por ejemplo, una vez a la semana), que es lo más recomendable para la mayoría de usuarios.

No basta con activar TRIM en un solo punto: si tienes, por ejemplo, un sistema ext4 sobre LVM y éste a su vez sobre un volumen cifrado LUKS/dm-crypt, el comando TRIM tiene que atravesar las tres capas. Hay que habilitarlo en el sistema de ficheros, en LVM y en dm-crypt; de lo contrario, se pierde por el camino y el SSD sigue “ciego”.

Requisitos para poder usar TRIM y fstrim en Linux

Antes de liarte a tocar configuraciones conviene comprobar que tu equipo cumple unos mínimos. Hoy en día casi cualquier distro moderna pasa el corte, pero merece la pena verificarlo, sobre todo si el hardware o el sistema ya tienen unos años.

1. Soporte TRIM en el sistema operativo. En Linux, el kernel soporta TRIM desde la rama 2.6.28, y su integración generalizada se fue consolidando alrededor de 2.6.33 en adelante. Si usas una distribución medianamente actual, tu kernel soporta TRIM sin problema, pero con SSD siempre es buena idea usar un kernel lo más reciente posible.

2. SSD con firmware compatible TRIM. Prácticamente todas las unidades SSD actuales lo soportan, pero conviene confirmarlo. Una forma típica es ejecutar en una terminal:

hdparm -I /dev/sdX | grep «TRIM supported»

Si aparece algo similar a «TRIM supported» o «Data Set Management TRIM supported» estás de enhorabuena. Sustituye /dev/sdX por la unidad real (sda, sdb…), sin número de partición. Si prefieres, también puedes usar lsblk –discard para ver capacidades de descarte en cada dispositivo de bloque.

3. Sistema de ficheros con soporte FITRIM. fstrim solo funciona sobre sistemas de ficheros que implementan la llamada ioctl FITRIM. Entre ellos están btrfs, ext3, ext4, gfs2, jfs, ocfs2, xfs, f2fs, vfat, ntfs-3g y otros modernos. En el contexto de Linux de escritorio, lo habitual es encontrarse ext4, Btrfs o XFS, que soportan TRIM sin problemas.

4. Herramientas de usuario adecuadas. El binario fstrim forma parte del paquete util-linux, que en la mayoría de distros viene instalado de serie. Si quieres asegurarte, puedes hacer:

sudo apt install util-linux

En distribuciones basadas en RPM o en otras familias bastará con usar el gestor de paquetes equivalente (dnf, zypper, pacman con el nombre del paquete correspondiente, etc.).

TRIM continuo vs TRIM periódico: qué elegir en Linux

En Linux hay dos grandes maneras de activar TRIM: en tiempo real o cada cierto intervalo. Por debajo hacen cosas similares, pero el impacto en rendimiento, desgaste y recuperación de datos cambia bastante.

1. TRIM continuo (opción discard en /etc/fstab). Consiste en añadir la opción discard a las opciones de montaje en /etc/fstab. Así, cada vez que borras un fichero, el kernel envía inmediatamente los descartes al SSD. Es cómodo porque te olvidas, pero en la práctica introduce algunos inconvenientes.

Los problemas típicos del TRIM continuo son varios: más operaciones de lectura/escritura en el SSD, pequeñas pausas o microcortes en ciertas cargas de trabajo, posible degradación del rendimiento bajo determinadas controladoras y, sobre todo, dificultad extrema para recuperar un archivo borrado por error, porque la unidad marca los bloques como libres casi al instante.

Algunas grandes distribuciones (Ubuntu, Debian, Manjaro, Fedora, etc.) durante años optaron por el enfoque continuo o mixto, añadiendo discard en fstab o integrando TRIM de forma automática. Con el tiempo, la recomendación de la mayoría de wikis (Debian, Arch, etc.) ha ido virando hacia el uso de fstrim periódico, dejando el montaje con discard solo para casos muy concretos.

2. TRIM periódico (fstrim lanzado por un temporizador o cron). Este enfoque se basa en ejecutar fstrim de forma programada (una vez al día, a la semana, o con la frecuencia que quieras) sobre los sistemas de ficheros montados que lo soporten. En distros con systemd esto se hace con el timer fstrim.timer, que normalmente está configurado para correr semanalmente.

La gran ventaja del TRIM periódico es que separa las operaciones de borrado lógico de las internas del SSD. Cuando eliminas un fichero, el sistema solo actualiza las estructuras del sistema de ficheros y, más tarde, cuando se ejecuta fstrim, se envían en bloque los descartes. Esto reduce el impacto en el día a día, evita microparones y permite juntar muchos bloques liberados en una sola pasada.

Además, usar fstrim de manera periódica te ayuda a detectar errores de configuración: si alguna capa (LVM, dm-crypt…) no está pasando correctamente los TRIM, fstrim suele devolver un error que te pone sobre la pista. Con discard en fstab, esos fallos normalmente pasan desapercibidos y crees que todo va bien, cuando en realidad el SSD nunca recibe la información.

Por último, el enfoque periódico te deja una pequeña ventana temporal para recuperar archivos borrados por accidente. Mientras no se haya ejecutado el próximo fstrim, es posible que las herramientas de recuperación aún encuentren los bloques, cosa que con discard activo continuamente es prácticamente imposible.

Cómo desactivar TRIM continuo (discard) en /etc/fstab

Si tu distribución ha montado automáticamente las particiones del SSD con la opción discard, lo ideal es retirarla y pasar a un modelo de TRIM periódico. El cambio es sencillo, pero hay que hacerlo con cuidado para no romper el arranque.

1. Edita /etc/fstab como root. Por ejemplo:

sudo nano /etc/fstab

2. Busca las entradas que montan tus sistemas de ficheros en la SSD (/, /home, /boot, swap, etc.) y localiza la opción discard entre las opciones de montaje. Un ejemplo típico sería algo así:

UUID=XXXX / ext4 defaults,noatime,discard 0 1

3. Elimina únicamente la palabra discard, dejando el resto de opciones intactas. En el ejemplo anterior, quedaría:

UUID=XXXX / ext4 defaults,noatime 0 1

Es muy recomendable mantener la opción noatime, ya que impide que el sistema escriba en disco la fecha del último acceso cada vez que lees un archivo. Esta simple opción reduce el número de escrituras tanto en SSD como en HDD y mejora el rendimiento general.

4. Guarda los cambios, cierra el editor y reinicia el sistema. A partir de ese momento, el kernel ya no enviará TRIM en tiempo real para cada borrado, y podrás gestionar el descarte de bloques únicamente con fstrim y sus temporizadores.

Activar fstrim periódico con systemd

La mayoría de distribuciones modernas que usan systemd traen un servicio y un timer llamados fstrim.service y fstrim.timer. El objetivo del timer es lanzar el servicio automáticamente con una cadencia determinada, normalmente una vez a la semana.

1. Asegúrate de tener util-linux instalado (porque ahí viene fstrim). En Debian, Ubuntu y derivados:

sudo apt install util-linux

2. Habilita el temporizador de fstrim para que arranque en cada inicio:

sudo systemctl enable fstrim.timer

3. Arranca el timer inmediatamente sin esperar al próximo reinicio:

sudo systemctl start fstrim.timer

4. Verifica el estado del temporizador para asegurarte de que está activo y a la espera de su próxima ejecución:

sudo systemctl status fstrim.timer

La salida típica mostrará algo como «active (waiting)» y un campo Trigger indicando cuándo se lanzará el próximo fstrim. Por ejemplo, los lunes a medianoche. También verás desde cuándo está activo el temporizador y si se ha ejecutado ya alguna vez.

En muchas distros, fstrim.timer está configurado para ejecutarse semanalmente (OnCalendar=weekly) con cierto margen de una hora (AccuracySec=1h). El ajuste de persistencia (Persistent=true) hace que, si el equipo estaba apagado cuando tocaba pasar fstrim, la tarea se ejecute en cuanto vuelva a encenderse.

Ver la frecuencia y el historial de ejecución de fstrim

Si quieres curiosear cómo está programado exactamente fstrim.timer, puedes inspeccionar su unidad de systemd. En muchas instalaciones encontrarás el archivo enlazado en:

cat /etc/systemd/system/timers.target.wants/fstrim.timer

El bloque suele incluir directivas como OnCalendar=weekly, AccuracySec=1h y Persistent=true. Si dominas la sintaxis de systemd.timer puedes cambiar la periodicidad por algo más fino, por ejemplo para que se ejecute ciertos días concretos u horas específicas.

Para comprobar cuándo se ejecutó TRIM por última vez y cuándo volverá a hacerlo, puedes usar:

systemctl list-timers fstrim.timer –all

La salida te mostrará columnas como NEXT, LEFT, LAST y PASSED: fecha de la próxima ejecución, tiempo que falta, última ejecución y cuánto tiempo ha pasado desde entonces. Es una forma rápida de confirmar que fstrim realmente está entrando en acción y no se ha quedado a medio configurar.

Si te interesa ver los registros detallados del timer y del servicio, recurre a journalctl:

sudo journalctl -u fstrim.timer
sudo journalctl -u fstrim.service

Ten en cuenta que por defecto el journal puede ser volátil y perderse en cada reinicio. Si quieres que los logs de fstrim se conserven, puedes crear el directorio de logs persistentes y ajustar systemd-journald:

sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles –create –prefix /var/log/journal
sudo systemctl restart systemd-journald

Eso sí, activar logs persistentes implica duplicar algo de información y usar más espacio en disco, aunque en la práctica el impacto suele ser asumible.

Forzar una pasada de fstrim bajo demanda

Hay situaciones en las que puede interesarte lanzar TRIM antes de lo programado. Por ejemplo, después de haber borrado cantidades grandes de datos, tras una migración o al “sanear” un SSD que viene de otro sistema operativo.

Tienes varias opciones para ejecutar fstrim manualmente. La más típica es aplicar TRIM a todos los sistemas de ficheros montados que lo soporten:

sudo fstrim -v -a

La opción -v hace que fstrim muestre cuántos bytes ha descartado en cada sistema de ficheros, lo cual viene fenomenal para verificar que realmente está trabajando y para detectar particiones donde no se envían descartes (posible falta de soporte en alguna capa).

Si solo quieres aplicar TRIM a una partición concreta, basta con indicar el punto de montaje:

sudo fstrim -v /
sudo fstrim -v /home
sudo fstrim -v /boot

Otra opción rápida es arrancar el timer y el servicio al momento con la opción –now:

sudo systemctl enable fstrim.timer –now

Este comando habilita el temporizador (si no lo estaba) y además provoca su ejecución inmediata, ideal si acabas de configurarlo y quieres darle una primera pasada al SSD sin esperar a la ventana programada.

Activar TRIM en LVM y en particiones cifradas con dm-crypt

Cuando usas LVM y cifrado de disco, es fácil que los TRIM se pierdan por el camino si no ajustas cada capa. El esquema típico sería: dm-crypt (LUKS) encima del dispositivo físico, LVM encima de dm-crypt y sistemas de ficheros (ext4, Btrfs…) encima de LVM. El objetivo es que los descartes emitidos por el sistema de ficheros consigan atravesar las tres capas hasta el SSD.

1. Habilitar TRIM en LVM: opción issue_discards. LVM necesita que activemos el envío de descartes a los dispositivos subyacentes. Esto se controla con el parámetro issue_discards en su archivo de configuración:

sudo nano /etc/lvm/lvm.conf

Dentro del bloque devices { … } busca la línea issue_discards y cambia su valor a 1 (si está a 0):

devices {
issue_discards = 1
}

Guarda los cambios y reinicia el sistema para que LVM empiece a propagar los TRIM hacia los dispositivos físicos o cifrados que tenga por debajo.

2. Habilitar TRIM en dm-crypt (LUKS): opción discard en /etc/crypttab. En el caso de particiones cifradas, hay que editar el archivo donde se definen los volúmenes:

sudo nano /etc/crypttab

En la columna de opciones agrega discard para el volumen que te interese. Un ejemplo típico:

sda3_crypt /dev/sda3 none luks,discard

Con esto le dices a dm-crypt que permita pasar los comandos TRIM hacia el dispositivo real. Es importante reseñar que activar TRIM sobre volúmenes cifrados tiene implicaciones de privacidad: al marcar ciertos sectores como libres, se filtra información sobre qué áreas del disco están en uso y cuáles no, lo cual puede ser relevante en escenarios de seguridad muy estrictos.

3. Regenerar el initramfs para aplicar los cambios de LVM y dm-crypt. Tras tocar /etc/lvm/lvm.conf o /etc/crypttab, es habitual que tengas que rehacer la imagen de arranque para que los cambios se apliquen desde el boot:

sudo update-initramfs -u -k all

En distribuciones tipo Red Hat el equivalente suele ser dracut -f. Una vez generadas las nuevas imágenes, reinicia la máquina para que todo arranque con la nueva configuración de TRIM en LVM y dm-crypt.

TRIM y fstrim en volúmenes VDO y escenarios de deduplicación

Si trabajas con tecnologías como VDO (Virtual Data Optimizer) o capas de deduplicación, TRIM adquiere una dimensión extra. En estos casos hay un mapeo entre bloques lógicos y físicos con deduplicación de datos, y el comando TRIM se usa para liberar bloques lógicos que ya no se utilizan, lo que a su vez acaba liberando bloques físicos.

Una forma habitual de comprobar el impacto de fstrim en un volumen VDO es seguir una serie de pasos medidos: preparar una tabla para registrar datos, recortar el sistema de ficheros, anotar uso de espacio, crear un archivo de prueba, volver a medir, borrar y recortar otra vez.

El flujo típico sería algo así: primero ejecutas fstrim en el sistema de ficheros para partir de una situación “limpia”; después consultas cuántos bloques lógicos y físicos está usando el volumen VDO con sus herramientas; más tarde creas un archivo de datos no duplicados (por ejemplo, 1 GiB) y verificas que el uso de bloques lógicos y físicos sube de forma esperable.

Si a continuación borras ese archivo sin recortar, verás que el sistema de ficheros sabe que hay espacio libre, pero VDO no refleja cambios en su contador de bloques. En cuanto vuelves a lanzar fstrim, el sistema de ficheros detecta los huecos libres, envía TRIM al volumen VDO y éste libera los bloques lógicos correspondientes, que a su vez acaban liberando bloques físicos deduplicados.

Este tipo de pruebas deja claro que, en entornos con capas adicionales como VDO, fstrim es clave para que la deduplicación y la compresión funcionen como es debido, liberando realmente espacio en las capas inferiores en lugar de limitarse a marcar bloques como libres solo en el sistema de ficheros.

Comprobar la salud real del SSD: más allá de fstrim

Aunque tengas fstrim configurado, eso no garantiza por sí solo que el SSD esté en perfecto estado. Hay equipos donde, por distintas razones, muchos bloques nunca se han llegado a recortar y el disco termina con un rendimiento de lectura ridículo comparado con sus especificaciones.

Una forma sencilla de tomarle el pulso a la unidad es usar la herramienta gráfica «Discos» (GNOME Disks) y lanzar una prueba de rendimiento de lectura. Un SSD sano suele mostrar una gráfica bastante plana a un nivel de MB/s cercano al máximo del dispositivo, con pequeñas variaciones, pero sin valles profundos constantes. Para análisis más detallados puedes recurrir a herramientas gratuitas para comprobar la salud.

Cuando ves una gráfica plagada de caídas, con lecturas que se quedan por debajo del 30% del rendimiento esperado, es muy posible que la unidad esté sufriendo por falta de TRIM en grandes zonas. A veces esto viene de reutilizar un SSD que antes estuvo lleno bajo Windows, de particionar encima sin hacer blkdiscard, o de años de uso sin recortar adecuadamente.

En estos escenarios avanzados hay quien recurre a herramientas como blkdiscard o hdparm para liberar manualmente grandes rangos del dispositivo. blkdiscard puede trimear una partición o un disco entero de golpe, mientras que hdparm permite scripts que liberan sectores de forma gradual. Son técnicas potentes pero peligrosas: usadas sin cuidado destruyen todos los datos, así que solo son viables cuando vas a reinstalar o rehacer el esquema de particiones.

Lo interesante es que, tras un descarte masivo correctamente hecho y una nueva instalación con TRIM bien configurado, esos SSD “lentos” suelen recuperar un rendimiento muy cercano al de fábrica. Y lo importante aquí no es solo la velocidad: si la controladora cree que buena parte de la unidad está ocupada cuando en realidad está libre, el nivelado de desgaste dispone de menos margen y el SSD puede envejecer antes de tiempo.

Optimizar montajes, swap y temporales para SSD en Linux

Además de TRIM, hay varias afinaciones clásicas que merece la pena aplicar cuando usas SSD, tanto por rendimiento como por reducir escrituras innecesarias.

1. Opciones de montaje en /etc/fstab. La más importante para un SSD es noatime, que impide actualizar el tiempo de último acceso en cada lectura de archivos. Sustituir atime por noatime reduce un buen número de escrituras pequeñas y beneficia a cualquier unidad, especialmente a los SSD.

En un sistema ext4 típico, tu entrada de fstab para la raíz podría verse así:

UUID=XXXX / ext4 noatime,errors=remount-ro 0 1

Antes de editar fstab conviene hacer siempre una copia de seguridad, porque un error tipográfico ahí puede dejar el sistema sin arrancar. Por ejemplo:

sudo cp /etc/fstab /etc/fstab.old

2. Reducir el uso de swap ajustando parámetros del kernel. Aunque los SSD soportan muchas escrituras, sigue siendo razonable no abusar de la swap si tienes RAM suficiente. En Linux puedes controlar el comportamiento con varios parámetros en /etc/sysctl.conf, por ejemplo:

vm.swappiness=1
vm.vfs_cache_pressure=50
vm.dirty_writeback_centisecs=1500
vm.dirty_expire_centisecs=4500
vm.dirty_ratio=30
vm.dirty_background_ratio=15

Con valores así le dices al kernel que apure más la RAM antes de tirar de swap y que gestione de forma algo más conservadora las escrituras diferidas, lo que suele traducirse en menos actividad constante sobre la unidad SSD y una experiencia más fluida.

3. Montar /tmp y otros directorios temporales en RAM. Otra práctica bastante extendida es montar /tmp (e incluso /var/tmp o /var/spool) sobre tmpfs, de modo que los archivos temporales vivan en memoria y no en el SSD. En equipos con 4 GB de RAM o más suele ser perfectamente viable.

Para hacerlo, se añaden líneas como estas a /etc/fstab:

tmpfs /tmp tmpfs noatime,nodiratime,nodev,nosuid,mode=1777,defaults 0 0
tmpfs /var/tmp tmpfs noatime,nodiratime,nodev,nosuid,mode=1777,defaults 0 0

Esto consigue que los temporales se creen en RAM, se borren automáticamente al reiniciar y no generen escrituras en el SSD. Cambia ligeramente el comportamiento de algunas aplicaciones que esperan que /var/tmp persista entre reinicios, así que conviene valorar si en tu caso concreto tiene sentido.

4. Actualizar initramfs tras cambios importantes. Siempre que modifiques opciones críticas de montaje, crypttab o lvm.conf, es buena práctica regenerar todas las imágenes initramfs con:

sudo update-initramfs -u -k all

En sistemas tipo Fedora o RHEL, el comando habitual sería dracut -f. Esto asegura que los cambios se apliquen desde el arranque, especialmente en lo relativo a volúmenes cifrados y LVM.

TRIM, fstrim y distros concretas: Ubuntu, Fedora, Debian y compañía

En el panorama actual, casi todas las distros de escritorio importantes ya integran algún tipo de TRIM periódico por defecto, especialmente en instalaciones nuevas sobre SSD.

Ubuntu, por ejemplo, lleva tiempo activando TRIM de forma automática en sistemas instalados en SSD. Durante años empleó un script en /etc/cron.weekly/fstrim que ejecutaba:

/sbin/fstrim –all || true

De esta forma, una vez a la semana se recortan todas las particiones montadas que lo soporten, manteniendo el SSD en buen estado sin necesidad de que el usuario toque nada. En versiones recientes la tendencia general es ir delegando estas tareas en systemd timers, pero la idea base es la misma.

Fedora, por su parte, decidió habilitar fstrim por defecto a partir de la versión 32, después de años sin hacerlo pese a ser una distribución muy automatizada. En su caso también se apoya en el servicio y temporizador fstrim.timer para sistemas con systemd, de modo que los usuarios con SSD disfrutan de TRIM periódico tras la instalación sin necesidad de configuración manual.

En Debian 10 (Buster) y posteriores, la propia documentación oficial recomienda usar kernels recientes, firmware actualizado para el SSD y sistemas de ficheros como ext4 o Btrfs. También insiste en no llenar en exceso la unidad y en usar opciones de montaje como noatime, junto con la activación de fstrim.timer para gestionar TRIM sin necesidad de discard continuo.

Las wikis de Arch Linux y Debian coinciden bastante en la filosofía general: evitar el montaje con discard salvo casos muy específicos, preferir fstrim periódico, y prestar atención a las capas de LVM y dm-crypt para garantizar que los comandos TRIM llegan al SSD. Siguiendo estas pautas, y combinándolas con buena alineación de particiones y suficiente espacio libre, la mayoría de SSD ofrecerán un rendimiento estable durante muchos años.

Configurar correctamente el uso de fstrim en Linux es menos complicado de lo que parece y marca una diferencia clara tanto en rendimiento como en longevidad del SSD: basta con asegurarte de que tu hardware y sistema soportan TRIM, desactivar el discard continuo, habilitar fstrim.timer, revisar LVM y dm-crypt si los usas y acompañarlo de unas cuantas buenas prácticas (noatime, temporales en RAM, swap ajustada); con ese conjunto de ajustes dejarás tu SSD bien optimizado y evitarás que, con el paso del tiempo, se convierta en el cuello de botella silencioso de tu sistema.