¿Qué es el sistema de archivos de Linux y cuál elegir?

La elección rápida: cuál te conviene según tu uso

Si quieres decidir sin leer todo ahora, aquí va directo:

1. Para la mayoría, XFS. Es la opción por defecto en distribuciones como RHEL y derivadas para particiones grandes. Asigna inodos de forma dinámica, soporta volúmenes y archivos de hasta 8 EiB y mantiene buen rendimiento con archivos grandes y uso continuado. Conviene si tu equipo es de uso general con discos actuales de 1 TiB o más y no planeas reducir la partición después.

1. Si buscas compatibilidad y reparación sencilla, ext4. Lleva desde 2008 como estándar, lo reconoce cualquier live USB y se repara con e2fsck sin herramientas extra. Conviene para disco de sistema que vas a mover entre equipos, discos externos en Linux y quien quiere documentación abundante para recuperar el sistema.

1. Si necesitas snapshots y checksums, btrfs. Crea instantáneas casi instantáneas, comprime con zstd y verifica integridad con scrub. Conviene para estaciones de trabajo con copias frecuentes y detección de corrupción. No conviene si tu plan es RAID 5/6 puro de btrfs sin protección adicional o cargas intensas de bases de datos sobre copy-on-write sin ajustes.

Datos comprobados en septiembre de 2026.

Qué es el sistema de archivos y por qué no es intercambiable

El sistema de archivos es la capa que organiza cómo se guardan, nombran y recuperan los archivos en el disco. No es un formato estético: define límites, cómo se recupera tras un corte de luz y si puedes crecer o reducir el volumen sin formatear.

Glosario mínimo para decidir:

• Inodo: ficha que describe un archivo (permisos, fechas, dónde están sus bloques). Cada archivo consume un inodo. Si se acaban, no creas archivos aunque quede espacio libre.
• Journaling: diario donde el sistema anota cambios antes de escribirlos. Si se corta la energía, reproduce el diario y evita dejar el sistema a medias. ext4 y XFS lo usan; btrfs usa otro enfoque.
• Copy-on-write (COW): al modificar un archivo o crear un snapshot, btrfs no sobrescribe el bloque original, escribe el nuevo en otro sitio. Permite snapshots y vuelta atrás barata, pero genera más fragmentación si reescribes mucho el mismo archivo.
• Crecimiento / reducción: crecer es ampliar el volumen en caliente; reducir es encogerlo. No todos lo permiten y eso condiciona cómo particionas el primer día.

Elegir mal obliga a copiar todo fuera, reformatear y restaurar. Elegir bien te ahorra esa migración.

Cómo elegir: los 4 criterios que separan ext4, XFS y btrfs

No elijas por nombre. Estos cuatro puntos se verifican con una cifra o con un sí/no y son los que cambian el día a día.

1. Gestión de inodos. ext4 crea un número fijo al formatear (controlado con mkfs.ext4 -i o -N). Si alojas millones de archivos pequeños y no ajustas ese parámetro, te quedas sin inodos antes que sin espacio. XFS y btrfs asignan inodos de forma dinámica según se necesitan, por eso escalan mejor con muchos archivos sin precalcular nada.

2. Tamaño máximo de archivo y volumen. ext4 llega a 16 TiB por archivo y 1 EiB por volumen. XFS y btrfs llegan a 8 EiB por archivo y 8 EiB y 16 EiB por volumen respectivamente. Si trabajas con vídeo sin comprimir, imágenes de máquina virtual o ficheros de más de 16 TiB, ext4 se queda corto.

3. Integridad con checksums. btrfs guarda checksum de datos y metadatos y puede detectar corrupción silenciosa con btrfs scrub. ext4 y XFS verifican metadatos con checksum, pero no validan el contenido del archivo por defecto. Si te importa saber que lo que lees es lo que se escribió, este punto inclina la balanza.

4. Posibilidad de reducir volumen. ext4 y btrfs permiten reducir (ext4 offline, btrfs online). XFS solo permite crecer, no encoger. Si dudas del reparto entre / y /home o entre máquinas virtuales, esa limitación pesa desde el primer particionado.

Tabla comparativa de sistemas de archivos

Sistema	Asignación de inodos	Tamaño máximo archivo	Tamaño máximo volumen	Checksum de datos	Shrink online	Caso ideal
ext4	Fija al formatear (mkfs.ext4 -i)	16 TiB	1 EiB	No	No (requiere offline con resize2fs)	Equipo general, disco externo Linux, rescate sencillo
XFS	Dinámica	8 EiB	8 EiB	No	No	Servidor, vídeo, bases de datos, archivos >16 TiB
btrfs	Dinámica	8 EiB	16 EiB	Sí	Sí	Snapshots, compresión, verificación de integridad

ext4 y XFS protegen metadatos con journaling y checksums de metadatos; btrfs protege datos y metadatos con checksums y copy-on-write. La diferencia práctica es si detectas corrupción del contenido o solo del índice.

ext4 — el estándar general para compatibilidad

ext4 es la evolución de ext3, estable desde 2008 y presente en toda distribución Linux. Corre en Linux y es el que más herramientas de rescate conocen los técnicos. Su madurez hace que cualquier USB de recuperación lo monte y que e2fsck esté disponible sin instalar paquetes extra.

Para quién sí:

• Equipo de escritorio o portátil de uso general donde quieres que todo lo abra cualquier Linux.
• Discos externos que solo usarás en Linux y donde te interesa reparar fácil tras un apagón.
• Instalaciones donde prefieres reducir la partición más adelante sin migrar a otro sistema de archivos.

Para quién no:

• Repositorios con millones de archivos pequeños si no ajustas inodos al formatear. Con el valor por defecto, un df -i puede marcar 100% de inodos usados con el disco al 50% de capacidad.
• Volúmenes donde necesitas archivos de más de 16 TiB. Ahí el límite por archivo de ext4 te bloquea aunque el volumen sea mayor.

Pega real: al ser el más compatible, su diseño asume crear la tabla de inodos al principio. Si te quedas corto, la única salida es respaldar, reformatear con otro -i y restaurar.

Ejemplo con cifras: en un disco de 2 TiB formateado con el valor por defecto de un inodo cada 16384 bytes, obtienes unos 131 millones de inodos. Si guardas 200 millones de archivos de 4 KiB, agotas inodos con ~800 GiB ocupados y df -h aún muestra 1,2 TiB libres. Con mkfs.ext4 -i 4096 multiplicas los inodos y evitas ese bloqueo.

Opciones de formateo y montaje en ext4 que importan

• mkfs.ext4 -i 4096 o -N para aumentar inodos si sabes que habrá muchísimos archivos pequeños; verifica después con df -i.
• mkfs.ext4 -m 1 en discos de datos para reservar menos porcentaje a root (por defecto 5%) y ganar espacio útil.
• Opción de montaje fast_commit (desde kernel 5.10) para acelerar operaciones con journal más ligero; útil en portátiles con SSD.
• Vigila df -i además de df -h. Si ves IUse% cerca de 80%, planifica limpieza o reformateo; sin inodos no creas archivos aunque haya gigabytes libres.
• Para reducir, desmonta y usa resize2fs; no es online como en btrfs, requiere ventana de mantenimiento.

XFS — alto rendimiento y archivos grandes sin límite práctico

XFS nació en SGI para IRIX y es el sistema por defecto en RHEL 7/8/9 para datos. Corre en Linux y está optimizado para archivos grandes, escritura paralela y volúmenes de varios TiB sin degradarse. Asigna inodos bajo demanda y usa allocation groups que reparten la carga en discos de alta concurrencia.

Para quién sí:

• Servidores, NAS y estaciones de vídeo que manejan ficheros de decenas o cientos de GiB y necesitan sostener throughput estable.
• Bases de datos y máquinas virtuales con imágenes grandes donde el límite de 16 TiB por archivo de ext4 se queda corto.
• Volúmenes que solo van a crecer. Con LVM, xfs_growfs amplía en caliente sin desmontar.

Para quién no:

• Quien necesita encoger la partición después para ceder espacio a otro volumen. XFS no implementa shrink.
• Usuarios que quieren checksums de datos nativos o snapshots a nivel de sistema de archivos sin capa extra (LVM o btrfs).

Pega real: su fortaleza es escalar hacia arriba. Si te equivocas dimensionando y dejas /home demasiado grande, no podrás recortarlo; tendrás que respaldar y recrear.

Ejemplo con cifras: una imagen de vídeo sin comprimir de 20 TiB no cabe como archivo único en ext4 (tope 16 TiB) y obliga a partirla. En XFS se guarda como un solo archivo dentro de un volumen de 8 EiB, y si el volumen se queda corto lo amplías online con xfs_growfs /punto_de_montaje tras extender el volumen lógico.

Limitación clave de XFS: solo crece

XFS permite xfs_growfs en caliente, pero no existe xfs_shrinkfs. Una vez asignado el espacio, no se devuelve sin borrar y reformatear.

• Planifica con LVM: crea volúmenes lógicos más pequeños de lo que crees necesitar y deja espacio libre en el volume group. Ampliar después son dos comandos; encoger sin LVM es migración completa.
• Si ya heredaste un XFS sobredimensionado, la ruta es xfsdump o rsync a otro volumen, recrear el XFS con el tamaño nuevo y restaurar.
• Para quien duda del reparto inicial entre sistema y datos, ext4 o btrfs dan más margen de corrección que XFS.

btrfs — snapshots e integridad nativa con condiciones

btrfs es un sistema copy-on-write con volumen, subvolúmenes y snapshots integrados. Corre en Linux y está en el kernel principal desde 2009. Suma compresión transparente (zlib, lzo, zstd), checksums de datos y metadatos y herramientas de verificación como btrfs scrub.

Para quién sí:

• Estaciones donde quieres volver atrás tras una actualización fallida con un snapshot de segundos y sin duplicar todo el disco.
• Usuarios que quieren detectar corrupción silenciosa del contenido, no solo de la tabla de archivos, y corregirla si hay réplica.
• Equipos con SSD donde la compresión zstd ahorra escritura y espacio en logs, bases ligeras y sistemas.

Para quién no:

• Producción que dependa de RAID 5/6 nativo de btrfs sin SAI ni controladora con batería. Ese modo ha tenido limitaciones de paridad y no es la elección prudente si no hay protección de energía y copia externa.
• Cargas de reescritura intensa (bases de datos grandes sobre COW) sin desactivar COW por archivo (chattr +C) o sin usar subvolumen dedicado. La fragmentación y el amplificado de escritura se notan.

Pega real: su potencia pide disciplina. Snapshots sin poda llenan el volumen y COW sin ajuste penaliza latencia en ciertos patrones.

Ejemplo con cifras: con un subvolumen de 500 GiB y snapshots diarios, crear un snapshot ocupa solo metadatos (megabytes) hasta que cambian bloques. Activar compress=zstd:3 suele recortar 15% a 30% en texto y logs, y un btrfs scrub start -B / verifica los checksums y reporta bloques corruptos para restaurar desde la réplica si existe.

Funciones diferenciales de btrfs

• [ ] Subvolúmenes y snapshots: crea btrfs subvolume create y btrfs snapshot -r para puntos de restauración instantáneos; restaura moviendo el subvolumen por defecto.
• [ ] Compresión transparente: compress=zstd:3 en /etc/fstab; ahorra espacio y reduce escritura sin comprimir a mano cada archivo.
• [ ] Scrub y checksums: btrfs scrub start / lee todo y valida checksums de datos y metadatos; detecta bit rot que otros sistemas no ven.
• [ ] Redimensionado online: btrfs filesystem resize -500G / y +500G crecen y encogen montado; útil para reequilibrar entre subvolúmenes.
• [ ] Balance y poda: btrfs balance y borrado programado de snapshots evitan que el pool se llene por bloques sin liberar.

Errores que salen caros al elegir y formatear

1. Quedarte sin inodos en ext4. Formatear con el valor por defecto y guardar millones de archivos de 4 KiB agota df -i al 100% con df -h al 50%. La solución no es borrar un poco: es respaldar y mkfs.ext4 -i 4096. Comprueba df -i el primer día.

1. Elegir XFS y luego querer reducir. Un volumen XFS de 1,8 TiB en un disco de 2 TiB no se encoge para ceder 500 GiB a otro sistema. Tendrás que volcar con xfsdump, recrear y restaurar. Si dudas del reparto, deja espacio libre en el volume group de LVM o elige un sistema que permita shrink.

1. Poner btrfs en RAID 5/6 sin red de seguridad. Montar RAID 5/6 puro de btrfs en producción sin SAI, sin copia externa y sin saber que la reconstrucción ante fallo de dos discos no está al nivel de una cabina, es arriesgar datos. Para paridad segura, usa RAID 1/10 de btrfs o RAID por hardware con batería y scrub periódico.

1. Dejar COW activo para todo en bases de datos. Una base que reescribe el mismo archivo genera fragmentación y más I/O. Crea un subvolumen con chattr +C antes de escribir datos o separa esa carga en XFS. No lo notes a los seis meses cuando el rendimiento ya cayó.

1. No probar el rescate. Asumir que e2fsck, xfs_repair o btrfs check estarán a mano sin haber arrancado un live USB y probado el montaje es llegar tarde. Verifica que tu medio de rescate monta el sistema elegido y que sabes el comando exacto antes de necesitarlo.

### Preguntas frecuentes

1. ¿Qué es el sistema de archivos en Linux y cuál debo elegir para mi equipo?

El sistema de archivos es el método que organiza y almacena los datos en un disco. Las opciones más comunes para Linux son ext4, Btrfs y XFS. La elección depende de tu uso: ext4 es la opción más estable y rápida para uso general, mientras que Btrfs ofrece snapshots y compresión que son útiles para copias de seguridad y ahorrar espacio.

2. ¿Qué diferencias prácticas hay entre ext4 y Btrfs?

ext4 es un sistema maduro, confiable y con bajo consumo de recursos, ideal para la mayoría de instalaciones. Btrfs es más moderno y añade funcionalidades como la compresión transparente de archivos y la creación de instantáneas (snapshots), pero puede tener un rendimiento ligeramente inferior en operaciones de escritura intensivas. Si valoras la simplicidad y el máximo rendimiento, elige ext4; si quieres herramientas avanzadas de administración de datos, considera Btrfs.

3. ¿Qué es Btrfs y cuándo es mejor usarlo que ext4?

Btrfs (pronunciado 'butterFS') es un sistema de archivos con soporte para copias en writable, compresión y manejo eficiente de volúmenes grandes. Es superior a ext4 para sistemas que requieren copias de seguridad frecuentes del estado del sistema, como servidores de desarrollo o estaciones de trabajo donde necesitas retroceder cambios rápidamente. Para un servidor de archivos básico o un escritorio sin necesidades especiales, ext4 sigue siendo la opción más sólida y probada.

Fuentes

1. SafeitexpertsLinux File System 2026 – SafeITExpertsconsultado el 23/09/2026
2. LinuxcommunityWhat is your favorite Linux FileSystem? – General Discussionsconsultado el 23/09/2026
3. LwnThe 2026 Linux Storage, Filesystem, Memory Management, and …consultado el 23/09/2026
4. CommandlinuxFile System Performance Comparison Statistics 2026consultado el 23/09/2026
5. LinuxfoundationLinux Storage, Filesystem, MM & BPF Summitconsultado el 23/09/2026