XFS en la vida real: cuándo usarlo, cómo montarlo bien y qué evitar

Si te dedicas a mover datos de verdad —terabytes que crecen todas las semanas, jobs en paralelo y servicios peleando por IO— XFS es ese martillo grande que quieres cuando el volumen y la concurrencia importan más que la pirotecnia de features. Nació para máquinas serias y, con los años, ha ido puliendo justo lo que marca la diferencia en producción: latencia estable bajo presión, journaling predecible y una arquitectura pensada para aprovechar CPUs múltiples sin que el FS se convierta en un cuello de botella.

Descubre como Linux 6.18 utiliza XFS

La idea clave: XFS organiza el espacio en extents y divide el sistema de archivos en allocation groups (AGs), que permiten que distintos hilos trabajen en paralelo sin pisarse. Esa separación, junto con árboles B y técnicas como la delayed allocation, mantiene controlado el coste de metadatos cuando hay mucha concurrencia. ¿Qué significa eso en la práctica? Menos “sorpresas” cuando deniegas un fichero grande, creas miles de objetos a la vez o lanzas un pipeline que satura los discos. En mi experiencia, cuando un equipo me pregunta por qué “la máquina se siente suave” durante picos, casi siempre hay XFS por debajo.

Frente a ext4 o Btrfs, XFS no busca serlo todo para todos; va a lo suyo: thruput sostenido y operaciones masivas de lectura/escritura con orden. Para redondear, su filosofía “infra primero” es muy pragmática: crecer online es trivial, cuotas de proyecto para limitar por carpeta/servicio sin hacks, y reflink (copy-on-write) para clonar ficheros al instante sin duplicar espacio. Cuando probé reflink en plantillas de máquinas y artefactos de build, el ahorro de tiempo y espacio fue inmediato.

Arquitectura en dos minutos: extents, AGs y journaling

Extents: en lugar de gestionar bloques sueltos, XFS agrupa rangos contiguos. Esto reduce fragmentación y el coste de metadatos en ficheros grandes.
Allocation groups: particionan el FS en zonas semi-independientes; múltiples CPUs pueden asignar/actualizar metadatos en paralelo. Esa es la magia que se nota en E/S concurrente.
Journaling de metadatos: el log registra cambios de estructura; la política es sobria y estable, lo que se traduce en tiempos consistentes y recuperación fiable si hay corte.

Cuándo XFS brilla de verdad

Aquí es donde XFS me ha pagado las facturas una y otra vez: ficheros grandes + E/S paralela. Piensa en:

Bases de datos (ficheros de datos y redo/transaction logs) cuando el motor no exige un FS CoW.
Almacenes de logs que absorben ráfagas y rotaciones con multi-hilo.
Imágenes de VM y contenedores: creación/clonado, mantenimiento y compactación con reflink para plantillas.
Backups y repositorios con escrituras concurrentes desde muchos agentes.
Procesamiento de datos/big data con etapas que leen/escriben artefactos gordos en paralelo.

La latencia estable importa tanto como el ancho de banda. XFS evita picos de “tail latency” que, en la práctica, son los que rompen SLAs cuando hay tormenta. Además, su journal predecible reduce sorpresas en ciclos de flush; si combinamos esto con buen almacenamiento (NVMe/RAID bien alineado), los resultados son consistentes. Como digo a menudo: a las tres de la mañana agradeces que xfs_repair sea sobrio y fiable.

Preparar el terreno: discos, RAID y alineamiento

XFS es muy agradecido cuando describes bien el layout físico. Tres reglas rápidas:

Alinea con el stripe del RAID (sea mdadm o HW).
En NVMe modernos, no fuerces parámetros “porque sí”; deja que el kernel y los defaults hagan su trabajo y mide antes de tunear.
TRIM en SSD/NVMe: programa fstrim.

Stripe/width y `mkfs.xfs`

Cuando uses RAID por bandas, informa a mkfs.xfs del tamaño de stripe (S) y stripe width (W). Ejemplo con RAID 10 de 4 discos, 256 KiB por banda:

# Crear FS (ajusta /dev/md0 y tamaños a tu caso)
mkfs.xfs -f -d su=256k,sw=2 -l size=1g /dev/md0
# su = stripe unit (tamaño de banda)
# sw = stripe width (nº de bandas que abarcan una escritura)

Para NVMe de un solo dispositivo, a menudo los defaults rinden mejor que forzar logbsize o logbufs. Mi pauta: empezar con defaults, correr un benchmark representativo (fio con colas/IO depth realistas) y sólo entonces tocar el log si hay evidencia.

Montaje sensato (SSD/NVMe)

Monta con relatime (es el estándar actual).
Usa noatime solo si mediste beneficio real en tu carga.
Programa TRIM semanal:

# systemd timer ya lo hace en muchas distros, si no:
sudo systemctl enable fstrim.timer
sudo systemctl start fstrim.timer
# o un cron semanal con: fstrim -av

Hands-on: crear, montar y crecer XFS en producción

Formateo con reflink y cuotas de proyecto

Si tu caso clona mucho (plantillas, builds, artefactos), activa reflink al formatear. Y si compartes el FS entre equipos o pipelines, prepara cuotas de proyecto para límites por carpeta.

# Reflink + quota de proyecto
mkfs.xfs -f -m reflink=1 -n ftype=1 /dev/mapper/vg_data-lv_xfs

ftype=1 asegura atributos de tipo de fichero compatibles con overlays. Tras el formateo:

# Montaje con cuotas de proyecto
mkdir -p /data
mount -o prjquota,relatime /dev/mapper/vg_data-lv_xfs /data

# /etc/fstab
/dev/mapper/vg_data-lv_xfs  /data  xfs  defaults,prjquota,relatime  0  0

Configurar proyectos (cuotas por carpeta):

# Mapear ID de proyecto a carpeta
echo "1001:/data/teamA" | sudo tee -a /etc/projects
echo "teamA:1001"       | sudo tee -a /etc/projid

# Crear carpeta y aplicar proyecto
mkdir -p /data/teamA
xfs_quota -x -c 'project -s teamA' /data

# Establecer límite (ej. 500 GiB)
xfs_quota -x -c 'limit -p bhard=500g teamA' /data

# Ver estado
xfs_quota -x -c 'report -p' /data

Montaje (fstab) y opciones típicas

UUID=xxxx-xxxx /data xfs relatime,prjquota 0 0
# Añade nofail si el FS no es crítico para el arranque.

Crecimiento online con `xfs_growfs`

Aquí XFS saca pecho: añade espacio al LV y crece el FS sin desmontar.

# 1) Extiende el LV (LVM)
lvextend -L +500G /dev/mapper/vg_data-lv_xfs

# 2) Crece XFS (montado)
xfs_growfs /data

# 3) Confirmar
xfs_info /data

Desfragmentación “en caliente”

Para cargas con mucha reescritura/rotación de ficheros grandes:

xfs_fsr -v /data
# O apuntar a un fichero/directorio específico
xfs_fsr -v /data/repos/bigfile.img

Operación a las 3 AM: herramientas que no fallan

Cuando algo huele raro, prefiero utilidades sobrias. Por eso digo: a las tres de la mañana, mejor herramientas que no te dejen tirado.

xfs_info: fotografía rápida de parámetros y layout (AGs, su/sw, tamaño de log…).
xfs_repair: reparación de metadatos. Úsalo con cabeza: desmonta el FS; si puedes, trabaja sobre un clon/snapshot.
xfs_metadump + xfs_mdrestore: para capturas de metadatos (útil en soporte).
xfsdump/xfsrestore: copias a nivel de FS, con inventario detallado y opciones de granularidad.
xfs_quota: ya lo viste; imprescindible para multi-tenant.

Ejemplo de chequeo rápido (sin reparar) con xfs_repair en modo no destructivo:

umount /data
xfs_repair -n /dev/mapper/vg_data-lv_xfs  # -n = no modifica, solo reporta
mount /data

Checklist de salud que me ha evitado sustos:

dmesg limpio: busca mensajes de I/O, timeout del controlador o advertencias de XFS.
xfs_info guardado en un runbook (saber cómo fue creado el FS).
smartctl/telemetría de la cabina sin sectores pendientes ni throttling térmico.
iostat -x y pidstat -d durante carga para ver colas y quién empuja.
fstrim -av al día si hay SSD/NVMe.

Limitaciones y anti-patrones

Nada es perfecto. XFS tiene bordes claros:

No reduce tamaño (shrink). Si te pasas aprovisionando, te toca migrar o recrear. Por eso repito: diseña con cabeza: mejor varios volúmenes medianos que un mega-volumen inmutable.
No trae snapshots nativos. Hazlos en LVM, Ceph, el hypervisor o la cabina.
Workloads de millones de ficheros minúsculos y metadatos hiper-calientes: XFS ha mejorado, pero hay escenarios donde ext4 o FS CoW con compresión pueden rendir mejor.
Tuning prematuro: tocar logbsize/logbufs sin métricas suele empeorar. En NVMe modernos, dejar que el kernel auto-tunee y medir antes de cambiar es, a menudo, la mejor decisión.

Estrategias para esquivar los bordes

Planificación de capacidad: varios LVs/FS medianos; así creces por partes y reduces blast radius.
Snapshots fuera del FS: LVM thin + reflink a nivel de FS es una pareja fantástica para CI/CD.
Almacenamiento bien descrito: su/sw correcto en RAID; TRIM en SSD; cachés del controlador documentadas.
Backups de verdad: xfsdump/restore o tu solución enterprise, pero con pruebas de restore calendarizadas.

Buenas prácticas y patrones de diseño

Multi-tenant con cuotas de proyecto: límites por carpeta/servicio, métricas claras y sin sorpresas de última hora.
Reflink por defecto si clonas plantillas/artefactos con frecuencia. El ahorro de espacio y tiempo se nota desde el día uno.
Observabilidad: exporta métricas de IO y FS; alerta ante colas altas sostenidas y latencias de tail.
Runbooks: deja documentado mkfs.xfs, mount, xfs_info y el motivo de cada opción.
Canary volumes: antes de consolidar todo en un gran pool, prueba con un volumen canario y tus cargas reales.
Governance del espacio: cuotas + reportes semanales para detectar crecimiento anómalo (artefactos huérfanos, logs sin rotar, dumps olvidados).

Sobre XFS

Si tu prioridad es concurrencia, ficheros grandes y estabilidad operativa, XFS te da justo lo que necesitas sin florituras. Crece en caliente, se deja gobernar por cuotas de proyecto y, con reflink, multiplica tu eficiencia en clonado. ¿La contrapartida? No hay shrink ni snapshots nativos, y no siempre es la mejor opción para enjambres de ficheros diminutos. Aun así, bien montado y con almacenamiento decente, XFS es ese martillo grande que resuelve problemas reales mientras tú duermes.

FAQs

¿Puedo reducir el tamaño de un XFS existente?
No. XFS sólo crece. Si te sobran cientos de gigas, planifica migrar o recrear con un tamaño más ajustado.

¿Cómo activo las cuotas por carpeta/proyecto?
Monta con prjquota, define /etc/projects y /etc/projid, aplica xfs_quota -x -c 'project -s NOMBRE' y define límites con xfs_quota -x -c 'limit -p ...'.

¿Cuándo usar noatime?
Solo si mediste que tu workload lo agradece. relatime suele ser suficiente y evita penalizaciones innecesarias.

¿Reflink siempre conviene?
Si clonas ficheros a menudo, sí. Si tu carga son escrituras intensivas sobre los mismos bloques (alta sobreescritura), mide el impacto antes.

¿Se recomienda separar el journal en otro dispositivo?
Solo si tu perfil de IOPS y latencia lo justifica (por ejemplo, un log en NVMe dedicado para un array más lento). En NVMe modernos, los defaults suelen ganar.

Opinión Personal

XFS no es el sistema de archivos “de moda”; es la herramienta que me ha salvado la piel cuando la carga aprieta y el reloj marca las 3 AM. Lo elijo porque prioriza lo que de verdad importa en producción: estabilidad de latencia bajo presión, un journal predecible y una arquitectura que reparte el trabajo entre CPUs sin dramas. Cuando gestionas bases de datos, almacenes de logs, imágenes de VM o repositorios que escriben a la vez desde mil hilos, XFS se comporta como un adulto en la sala: no promete fuegos artificiales, promete que no te fallará.

Me gusta su filosofía de “infra primero”. Crecer el sistema de archivos en caliente es rutinario (como debería ser), las cuotas de proyecto me permiten acotar por carpeta o servicio sin inventos, y reflink me da clones instantáneos para plantillas y artefactos sin duplicar espacio. Esa combinación reduce fricción operativa y te devuelve horas de vida que antes perdías moviendo datos de un lado a otro.

¿Tiene aristas? Sí, y agradecerás saberlas antes: XFS no hace shrink. Si te pasas aprovisionando, te tocará migrar o recrear. Tampoco trae snapshots nativos; para eso está LVM, el hypervisor o la cabina. Y aunque ha mejorado con ficheros pequeños, si tu mundo son millones de miniarchivos con metadatos hirviendo, a veces otra opción encaja mejor. Pero justo ahí está el punto: elegir con criterio. Para cargas de E/S paralela con ficheros grandes, XFS es el “martillo grande” que resuelve problemas reales y evita sorpresas.

En la práctica, mis reglas son simples: alinear bien con RAID, activar TRIM en SSD/NVMe, empezar con defaults sensatos y medir antes de tocar el log. Si clonas mucho, formatea con reflink; si compartes entornos, aplica cuotas de proyecto desde el día uno. Y, por favor, diseña con cabeza: mejor varios volúmenes medianos que un mega-volumen que luego no puedes reducir.

Esta es mi opinión tras años de golpes (y de éxitos) con XFS: menos ruido, más fiabilidad. Si lo montas bien, te olvidas de él… y esa es la mayor virtud que puede tener un sistema de archivos.

¿Tú cómo lo ves? ¿Te ha sacado XFS de un apuro o te ha dado guerra? Cuéntame tu experiencia en los comentarios: qué funcionó, qué no y qué ajustes te dieron mejores resultados.