La mayoría de las distribuciones modernas de Linux tienen por defecto el sistema de archivos ext4, al igual que las distribuciones anteriores de Linux tenían por defecto ext3, ext2 y, si retrocedes lo suficiente, ext.
Si es nuevo en Linux, o en los sistemas de archivos, es posible que se pregunte qué aporta ext4 a la mesa que ext3 no. También podría preguntarse si ext4 todavía está en desarrollo activo, dada la ráfaga de cobertura de noticias de sistemas de archivos alternativos como btrfs, xfs y zfs.
Más recursos de Linux
- Hoja de trucos de los comandos de Linux
- Hoja de trucos de comandos avanzados de Linux
- Curso en línea gratuito:Descripción general técnica de RHEL
- Hoja de trucos de red de Linux
- Hoja de trucos de SELinux
- Hoja de trucos de los comandos comunes de Linux
- ¿Qué son los contenedores de Linux?
- Nuestros últimos artículos sobre Linux
No podemos cubrir todo acerca de los sistemas de archivos en un solo artículo, pero intentaremos ponerlo al día sobre la historia del sistema de archivos predeterminado de Linux, dónde se encuentra y qué esperar.
Me basé en gran medida en los diversos artículos del sistema de archivos ext de Wikipedia, las entradas wiki de kernel.org en ext4 y mis propias experiencias mientras preparaba esta descripción general.
Una breve historia de ext
Sistema de archivos MINIX
Antes de que existiera ext, existía el sistema de archivos MINIX. Si no está al tanto de su historial de Linux, MINIX era un sistema operativo muy pequeño similar a Unix para microcomputadoras IBM PC/AT. Andrew Tannenbaum lo desarrolló con fines didácticos y publicó su código fuente (¡en formato impreso!) en 1987.
Aunque podía leer detenidamente la fuente de MINIX, en realidad no era un software libre y de código abierto (FOSS). Los editores del libro de Tannebaum requirieron una tarifa de licencia de $ 69 para operar MINIX, que estaba incluida en el costo del libro. Aún así, esto era increíblemente económico para la época, y la adopción de MINIX despegó rápidamente, superando pronto la intención original de Tannenbaum de usarlo simplemente para enseñar la codificación de los sistemas operativos. A lo largo de la década de 1990, podía encontrar instalaciones de MINIX prosperando en universidades de todo el mundo, y un joven Linus Torvalds usó MINIX para desarrollar el kernel de Linux original, anunciado por primera vez en 1991 y lanzado bajo la licencia GPL en diciembre de 1992.
Pero espera, este es un sistema de archivos artículo, ¿verdad? Sí, y MINIX tenía su propio sistema de archivos, en el que también se basaban las primeras versiones de Linux. Al igual que MINIX, podría describirse sin caridad como un ejemplo de "juguete" de este tipo:el sistema de archivos MINIX solo podía manejar nombres de archivo de hasta 14 caracteres y direcciones de solo 64 MB de almacenamiento. En 1991, el disco duro típico ya tenía un tamaño de 40-140 MB. ¡Linux claramente necesitaba un mejor sistema de archivos!
exterior
Mientras Linus pirateaba el incipiente kernel de Linux, Rémy Card trabajaba en el primer sistema de archivos ext. Implementado por primera vez en 1992, ¡solo un año después del anuncio inicial de Linux en sí mismo!, Ext resolvió el peor de los problemas del sistema de archivos MINIX.
La extensión de 1992 usó la nueva capa de abstracción del sistema de archivos virtual (VFS) en el kernel de Linux. A diferencia del sistema de archivos MINIX anterior, ext podía manejar hasta 2 GB de almacenamiento y manejar nombres de archivo de 255 caracteres.
Pero ext no tuvo un reinado largo, en gran parte debido a su marca de tiempo primitiva (solo una marca de tiempo por archivo, en lugar de las tres marcas separadas para la creación de inodos, el acceso a archivos y la modificación de archivos con los que estamos familiarizados hoy). Apenas un año después, ext2 se comió su almuerzo.
ext2
Rémy claramente se dio cuenta de las limitaciones de ext con bastante rapidez, ya que diseñó ext2 como su reemplazo un año después. Si bien ext todavía tenía sus raíces en los sistemas operativos de "juguete", ext2 fue diseñado desde el principio como un sistema de archivos de grado comercial, siguiendo los mismos principios que el sistema de archivos rápido Berkeley de BSD.
Ext2 ofreció tamaños de archivo máximos en gigabytes y tamaños de sistemas de archivos en terabytes, colocándolo firmemente en las grandes ligas de la década de 1990. Fue rápida y ampliamente adoptado, tanto en el kernel de Linux y eventualmente en MINIX, así como por módulos de terceros que lo hicieron disponible para MacOS y Windows.
Sin embargo, aún quedaban problemas por resolver:los sistemas de archivos ext2, como la mayoría de los sistemas de archivos de la década de 1990, eran propensos a una corrupción catastrófica si el sistema fallaba o perdía energía mientras los datos se escribían en el disco. También sufrieron pérdidas de rendimiento significativas debido a la fragmentación (el almacenamiento de un solo archivo en varios lugares, físicamente dispersos alrededor de un disco giratorio) a medida que pasaba el tiempo.
A pesar de estos problemas, ext2 todavía se usa en algunos casos aislados en la actualidad, más comúnmente, como un formato para unidades de memoria USB portátiles.
ext3
En 1998, seis años después de la adopción de ext2, Stephen Tweedie anunció que estaba trabajando para mejorarlo significativamente. Esto se convirtió en ext3, que se adoptó en la línea principal de Linux con kernel versión 2.4.15, en noviembre de 2001.
A Ext2 le había ido muy bien con las distribuciones de Linux en su mayor parte, pero, como FAT, FAT32, HFS y otros sistemas de archivos de la época, era propenso a la corrupción catastrófica durante la pérdida de energía. Si pierde energía mientras escribe datos en el sistema de archivos, puede quedar en lo que se llama un inconsistente estado:uno en el que las cosas se han dejado a medio hacer y medio deshechas. Esto puede resultar en la pérdida o corrupción de grandes extensiones de archivos no relacionados con el que se está guardando o incluso en la imposibilidad de montar todo el sistema de archivos.
Ext3 y otros sistemas de archivos de finales de la década de 1990, como NTFS de Microsoft, utilizan journaling para resolver este problema. El diario es una asignación especial en disco donde las escrituras se almacenan en transacciones; si la transacción termina de escribirse en el disco, sus datos en el diario se confirman al propio sistema de archivos. Si el sistema falla antes de que se confirme esa operación, el sistema recién reiniciado la reconoce como una transacción incompleta y la revierte como si nunca hubiera tenido lugar. Esto significa que el archivo en el que se está trabajando todavía puede perderse, pero el sistema de archivos en sí mismo permanece consistente, y todos los demás datos están seguros. Hay tres niveles de diario disponibles en la implementación del kernel de Linux de ext3:journal , pedido y reescritura .
- Diario es el modo de menor riesgo, escribiendo datos y metadatos en el diario antes de enviarlo al sistema de archivos. Esto garantiza la coherencia del archivo en el que se escribe, así como del sistema de archivos en su conjunto, pero puede disminuir significativamente el rendimiento.
- Pedido es el modo predeterminado en la mayoría de las distribuciones de Linux; el modo ordenado escribe metadatos en el diario pero envía los datos directamente al sistema de archivos. Como su nombre lo indica, el orden de operaciones aquí es rígido:primero, los metadatos se comprometen con la revista; en segundo lugar, los datos se escriben en el sistema de archivos y solo entonces los metadatos asociados en el diario se descargan en el propio sistema de archivos. Esto garantiza que, en caso de un bloqueo, los metadatos asociados con las escrituras incompletas aún estén en el diario, y el sistema de archivos puede desinfectar esas escrituras incompletas mientras revierte el diario. En el modo ordenado, un bloqueo puede provocar la corrupción del archivo o los archivos que se escriben activamente durante el bloqueo, pero el sistema de archivos en sí, y los archivos en los que no se escriben activamente, están garantizados como seguros.
- Reescribir es el tercer y menos seguro modo de registro diario. En el modo de reescritura, como en el modo ordenado, los metadatos se registran, pero los datos no. A diferencia del modo ordenado, los metadatos y los datos pueden escribirse en cualquier orden que tenga sentido para un mejor rendimiento. Esto puede ofrecer aumentos significativos en el rendimiento, pero es mucho menos seguro. Aunque el modo de reescritura todavía ofrece una garantía de seguridad para el propio sistema de archivos, los archivos que se escribieron durante o antes del bloqueo son vulnerables a pérdidas o corrupción.
Al igual que ext2 antes, ext3 usa direccionamiento interno de 16 bits. Esto significa que con un tamaño de bloque de 4K, el tamaño de archivo más grande que puede manejar es de 2 TiB en un tamaño máximo de sistema de archivos de 16 TiB.
ext4
Theodore Ts'o (quien para entonces era el desarrollador principal de ext3) anunció ext4 en 2006, y se agregó a la línea principal de Linux dos años después, en la versión 2.6.28 del kernel. Ts'o describe ext4 como una tecnología provisional que amplía significativamente ext3 pero aún depende de la tecnología antigua. Él espera que eventualmente sea suplantado por un verdadero sistema de archivos de próxima generación.
Ext4 es funcionalmente muy similar a ext3, pero brinda compatibilidad con sistemas de archivos grandes, resistencia mejorada a la fragmentación, mayor rendimiento y marcas de tiempo mejoradas.
Ext4 frente a ext3
Ext3 y ext4 tienen algunas diferencias muy específicas, en las que me centraré aquí.
Compatibilidad con versiones anteriores
Ext4 fue diseñado específicamente para ser lo más retrocompatible posible con ext3. Esto no solo permite que los sistemas de archivos ext3 se actualicen a ext4; también permite que el controlador ext4 monte automáticamente sistemas de archivos ext3 en modo ext3, por lo que no es necesario mantener las dos bases de código por separado.
Grandes sistemas de archivos
Los sistemas de archivos ext3 usaban direccionamiento de 32 bits, limitándolos a archivos de 2 TiB y sistemas de archivos de 16 TiB (suponiendo un tamaño de bloque de 4 KiB; algunos sistemas de archivos ext3 usan tamaños de bloque más pequeños y, por lo tanto, están aún más limitados).
Ext4 usa direccionamiento interno de 48 bits, lo que teóricamente hace posible asignar archivos de hasta 16 TiB en sistemas de archivos de hasta 1 000 000 TiB (1 EiB). Las primeras implementaciones de ext4 todavía estaban limitadas a sistemas de archivos de 16 TiB por algunas utilidades de usuario, pero a partir de 2011, e2fsprogs ha respaldado directamente la creación de sistemas de archivos ext4 de>16 TiB. Como ejemplo, Red Hat Enterprise Linux admite por contrato sistemas de archivos ext4 solo hasta 50 TiB y recomienda volúmenes ext4 que no superen los 100 TiB.
Mejoras en la asignación
Ext4 introduce muchas mejoras en la forma en que se asignan los bloques de almacenamiento antes de escribirlos en el disco, lo que puede aumentar significativamente el rendimiento de lectura y escritura.
Extensiones
Una extensión es un rango de bloques físicos contiguos (hasta 128 MiB, suponiendo un tamaño de bloque de 4 KiB) que se pueden reservar y direccionar a la vez. El uso de extensiones disminuye la cantidad de inodos requeridos por un archivo determinado y reduce significativamente la fragmentación y aumenta el rendimiento al escribir archivos grandes.
Asignación multibloque
Ext3 llamó a su asignador de bloques una vez por cada nuevo bloque asignado. Esto podría resultar fácilmente en una gran fragmentación cuando varios escritores están abiertos al mismo tiempo. Sin embargo, ext4 utiliza la asignación retrasada, lo que le permite fusionar escrituras y tomar mejores decisiones sobre cómo asignar bloques para las escrituras que aún no ha confirmado.
Asignación previa persistente
Al preasignar espacio en disco para un archivo, la mayoría de los sistemas de archivos deben escribir ceros en los bloques para ese archivo en el momento de la creación. Ext4 permite el uso de fallocate() en cambio, lo que garantiza la disponibilidad del espacio (e intenta encontrar un espacio contiguo para él) sin necesidad de escribir primero en él. Esto aumenta significativamente el rendimiento tanto en las escrituras como en las lecturas futuras de los datos escritos para las aplicaciones de base de datos y transmisión.
Asignación retrasada
Esta es una característica masticable y polémica. La asignación retrasada permite que ext4 espere para asignar los bloques reales en los que escribirá datos hasta que esté listo para enviar esos datos al disco. (Por el contrario, ext3 asignaría bloques de inmediato, incluso mientras los datos aún fluyen hacia un caché de escritura).
Retrasar la asignación de bloques a medida que los datos se acumulan en la memoria caché permite que el sistema de archivos tome decisiones más sensatas sobre cómo asignar esos bloques, lo que reduce la fragmentación (escritura y, más tarde, lectura) y aumenta significativamente el rendimiento. Desafortunadamente, aumenta el potencial de pérdida de datos en programas que no se han escrito específicamente para llamar a fsync() cuando el programador quiere asegurarse de que los datos se hayan vaciado por completo en el disco.
Digamos que un programa reescribe un archivo por completo:
fd=open("file" ,O_TRUNC); write(fd, data); close(fd);
Con sistemas de archivos heredados, close(fd); es suficiente para garantizar que el contenido de file se vaciará en el disco. Aunque la escritura no es, estrictamente hablando, transaccional, hay muy poco riesgo de perder los datos si se produce un bloqueo después el archivo está cerrado.
Si la escritura no tiene éxito (debido a errores en el programa, errores en el disco, pérdida de energía, etc.), tanto la versión original como la versión más reciente del archivo puede perderse o dañarse. Si otros procesos acceden al archivo mientras se está escribiendo, verán una versión corrupta. Y si otros procesos tienen el archivo abierto y no esperan que su contenido cambie, por ejemplo, una biblioteca compartida asignada a varios programas en ejecución, pueden fallar.
Para evitar estos problemas, algunos programadores evitan usar O_TRUNC en absoluto. En su lugar, podrían escribir en un nuevo archivo, cerrarlo y luego cambiarle el nombre al antiguo:
fd=open("newfile"); write(fd, data); close(fd); rename("newfile", "file");
Bajo sistemas de archivos sin asignación retrasada, esto es suficiente para evitar la corrupción potencial y los problemas de bloqueo descritos anteriormente:Dado que rename() es una operación atómica, no será interrumpida por un choque; y los programas en ejecución seguirán haciendo referencia a la versión antigua, ahora desvinculada, de file mientras tengan un identificador de archivo abierto. Pero debido a que la asignación retrasada de ext4 puede hacer que las escrituras se retrasen y se reordenen, rename("newfile","file") puede llevarse a cabo antes el contenido de newfile en realidad se escriben en el disco, lo que abre el problema de que los procesos paralelos obtengan malas versiones del file todo de nuevo.
Para mitigar esto, el kernel de Linux (desde la versión 2.6.30) intenta detectar estos casos de código comunes y forzar la asignación inmediata de los archivos en cuestión. Esto reduce, pero no evita, la posibilidad de pérdida de datos, y no ayuda en absoluto con los archivos nuevos. Si es desarrollador, tome nota:el solo La forma de garantizar que los datos se escriban en el disco inmediatamente es llamar a fsync() apropiadamente.
Subdirectorios ilimitados
Ext3 estaba limitado a un total de 32.000 subdirectorios; ext4 permite un número ilimitado. A partir del kernel 2.6.23, ext4 usa índices HTree para mitigar la pérdida de rendimiento con una gran cantidad de subdirectorios.
Comprobación de suma de diario
Ext3 no realizó una suma de verificación de sus diarios, lo que presentaba problemas para los dispositivos de disco o controlador con sus propios cachés, fuera del control directo del kernel. Si un controlador o un disco con su propio caché escribe fuera de orden, podría romper el orden de transacciones de diario de ext3, lo que podría dañar los archivos que se escriben durante (o durante algún tiempo antes) un bloqueo.
En teoría, este problema se resuelve mediante el uso de barreras de escritura:al montar el sistema de archivos, establece barrier=1 en las opciones de montaje, y el dispositivo respetará fsync() llama todo el camino hasta el metal. En la práctica, se ha descubierto que los dispositivos de almacenamiento y los controladores con frecuencia no respete las barreras de escritura:mejore el rendimiento (y los puntos de referencia, donde se comparan con sus competidores), pero abre la posibilidad de corrupción de datos que debería haberse evitado.
La suma de verificación del diario permite que el sistema de archivos se dé cuenta de que algunas de sus entradas no son válidas o están fuera de orden en el primer montaje después de un bloqueo. De este modo, se evita el error de revertir entradas de diario parciales o desordenadas y dañar aún más el sistema de archivos, incluso si los dispositivos de almacenamiento mienten y no respetan las barreras.
Comprobaciones rápidas del sistema de archivos
Bajo ext3, todo el sistema de archivos, incluidos los archivos eliminados y vacíos, requería verificación cuando fsck es invocado. Por el contrario, ext4 marca bloques y secciones no asignados de la tabla de inodos como tales, lo que permite que fsck para omitirlos por completo. Esto reduce en gran medida el tiempo para ejecutar fsck en la mayoría de los sistemas de archivos y ha sido implementado desde el kernel 2.6.24.
Marcas de tiempo mejoradas
Ext3 ofrecía marcas de tiempo granulares de un segundo. Si bien es suficiente para la mayoría de los usos, las aplicaciones de misión crítica buscan con frecuencia un control de tiempo mucho más estricto. Ext4 se pone a disposición de aquellas aplicaciones empresariales, científicas y de misión crítica al ofrecer marcas de tiempo en nanosegundos.
Los sistemas de archivos Ext3 tampoco proporcionaron suficientes bits para almacenar fechas posteriores al 18 de enero de 2038. Ext4 agrega dos bits adicionales aquí, extendiendo la época de Unix otros 408 años. Si está leyendo esto en 2446 AD, es de esperar que ya se haya movido a un mejor sistema de archivos, pero me hará póstumamente muy, muy feliz si todavía está midiendo el tiempo desde las 00:00 UTC del 1 de enero de 1970.
Desfragmentación en línea
Ni ext2 ni ext3 admitían directamente la desfragmentación en línea, es decir, la desfragmentación del sistema de archivos mientras estaba montado. Ext2 tenía una utilidad incluida, e2defrag , que hizo lo que su nombre indica, pero debía ejecutarse sin conexión mientras el sistema de archivos no estaba montado. (Esto es, obviamente, especialmente problemático para un sistema de archivos raíz). La situación era aún peor en ext3, aunque era mucho menos probable que ext3 sufriera una fragmentación severa que ext2, ejecutando e2defrag contra un sistema de archivos ext3 podría resultar en daños catastróficos y pérdida de datos.
Aunque originalmente se consideró que ext3 "no se ve afectado por la fragmentación", los procesos que emplean procesos de escritura paralelos masivos en el mismo archivo (por ejemplo, BitTorrent) dejaron en claro que este no era del todo el caso. Varios trucos y soluciones alternativas del espacio de usuario, como Shake, abordaron esto de una forma u otra, pero eran más lentos y, en varios aspectos, menos satisfactorios que un verdadero proceso de desfragmentación a nivel de kernel, consciente del sistema de archivos.
Ext4 aborda este problema de frente con e4defrag , una utilidad de desfragmentación en línea, en modo kernel, consciente del sistema de archivos, a nivel de bloque y extensión.
Desarrollo continuo de ext4
Ext4 es, como los Monty Python Una víctima de la peste dijo una vez:"¡Todavía no estoy muerta!". Aunque su desarrollador principal lo considera un mero recurso provisional en el camino hacia un sistema de archivos verdaderamente de última generación, ninguno de los candidatos probables estará listo (debido a problemas técnicos o de licencia) para su implementación como sistema de archivos raíz durante algún tiempo todavía.
Todavía hay algunas características clave que se están desarrollando en futuras versiones de ext4, incluida la suma de verificación de metadatos, compatibilidad con cuotas de primera clase y grandes bloques de asignación.
Suma de verificación de metadatos
Dado que ext4 tiene superbloques redundantes, la suma de verificación de los metadatos dentro de ellos ofrece al sistema de archivos una forma de averiguar por sí mismo si el superbloque principal está dañado y necesita usar un alternativo. Es posible recuperarse de un superbloque corrupto sin suma de verificación, pero el usuario primero debe darse cuenta de que fue corrupto, y luego intente montar manualmente el sistema de archivos usando una alternativa. Dado que montar un sistema de archivos de lectura y escritura con un superbloque primario corrupto puede, en algunos casos, causar más daños, ¡esta no es una solución suficiente, incluso con un usuario suficientemente experimentado!
En comparación con la suma de verificación por bloque extremadamente robusta que ofrecen los sistemas de archivos de próxima generación, como btrfs o zfs, la suma de verificación de metadatos de ext4 es una característica bastante débil. Pero es mucho mejor que nada.
Aunque suene como una obviedad, ¡sí, haga una suma de verificación de TODAS LAS COSAS! Hay algunos desafíos importantes para agregar sumas de verificación en un sistema de archivos después del hecho; consulte el documento de diseño para ver los detalles arenosos.
Soporte de cuota de primera clase
Espera, ¿cuotas? ¡Los hemos tenido desde los días ext2! Sí, pero siempre han sido una ocurrencia tardía, y siempre han apestado. Probablemente no valga la pena entrar en detalles peludos aquí, pero el documento de diseño establece las formas en que las cuotas se moverán del espacio de usuario al kernel y se aplicarán de manera más correcta y eficiente.
Grandes bloques de asignación
A medida que pasa el tiempo, esos molestos sistemas de almacenamiento se hacen cada vez más grandes. Con algunas unidades de estado sólido que ya usan tamaños de bloque de hardware de 8K, la limitación actual de ext4 a bloques de 4K se vuelve cada vez más limitante. Los bloques de almacenamiento más grandes pueden disminuir la fragmentación y aumentar significativamente el rendimiento, a costa de un mayor espacio "inactivo" (el espacio que queda cuando solo necesita una parte de un bloque para almacenar un archivo o la última parte de un archivo).
Puede ver los detalles peludos en el documento de diseño.
Limitaciones prácticas de ext4
Ext4 es un sistema de archivos robusto y estable, y es lo que la mayoría de la gente probablemente debería usar como sistema de archivos raíz en 2018. Pero no puede manejar todo. Hablemos brevemente sobre algunas de las cosas que no debería esperar de ext4, ahora o probablemente en el futuro.
Aunque ext4 puede abordar hasta 1 EiB (equivalente a 1 000 000 TiB) de datos, realmente, realmente no debería intentar hacerlo. Hay problemas de escala más allá de simplemente poder recordar las direcciones de muchos más bloques, y ext4 ahora (y probablemente nunca lo hará) escala muy bien más allá de 50-100 TiB de datos.
Ext4 tampoco hace lo suficiente para garantizar la integridad de sus datos. A pesar de que el registro en diario fue un gran avance en los días ext3, no cubre muchas de las causas comunes de corrupción de datos. Si los datos se corrompen mientras ya están en el disco, por hardware defectuoso, el impacto de los rayos cósmicos (sí, en serio) o la simple degradación de los datos con el tiempo, ext4 no tiene forma de detectar o reparar dicha corrupción.
Sobre la base de los dos últimos elementos, ext4 es solo un sistema de archivos puro , y no un administrador de volumen de almacenamiento. Esto significa que incluso si tiene varios discos y, por lo tanto, paridad o redundancia, de los que teóricamente podría recuperar datos corruptos, ext4 no tiene forma de saberlo o usarlo para su beneficio. Si bien es teóricamente posible separar un sistema de archivos y un sistema de administración de volúmenes de almacenamiento en capas discretas sin perder las funciones automáticas de detección y reparación de daños, no es así como se diseñan los sistemas de almacenamiento actuales y presentaría desafíos importantes para los nuevos diseños.
Sistemas de archivos alternativos
Antes de comenzar, una palabra de advertencia:Sea muy cuidado con cualquier sistema de archivos alternativo que no esté integrado en y no sea compatible directamente como parte del núcleo principal de su distribución!
Incluso si un sistema de archivos es seguro , usarlo como sistema de archivos raíz puede ser absolutamente aterrador si algo falla durante una actualización del kernel. Si no eres extremadamente se siente cómodo con la idea de arrancar desde medios alternativos y hurgar de forma manual y paciente en los módulos del kernel, las configuraciones de grub y DKMS desde un chroot... no se salga de la reserva con el sistema de archivos raíz en un sistema que le interese.
Puede haber buenas razones para usar un sistema de archivos que su distribución no admita directamente, pero si lo hace, le recomiendo que lo monte después el sistema está activo y utilizable. (Por ejemplo, puede tener un sistema de archivos raíz ext4, pero almacenar la mayoría de sus datos en un grupo zfs o btrfs).
XFS
XFS es tan principal como un sistema de archivos sin extensión en Linux. Es un sistema de archivos de diario de 64 bits que se ha integrado en el kernel de Linux desde 2001 y ofrece un alto rendimiento para sistemas de archivos grandes y altos grados de concurrencia (es decir, una gran cantidad de procesos que escriben en el sistema de archivos a la vez).
XFS se convirtió en el sistema de archivos predeterminado para Red Hat Enterprise Linux, a partir de RHEL 7. Todavía tiene algunas desventajas para los usuarios domésticos o de pequeñas empresas, en particular, es una verdadera molestia cambiar el tamaño de un sistema de archivos XFS existente, hasta el punto de que generalmente hace más. tiene sentido crear otro y copiar sus datos.
Si bien XFS es estable y tiene un buen rendimiento, no hay una diferencia de uso final concreta suficiente entre él y ext4 para recomendar su uso en cualquier lugar que no sea el predeterminado (p. ej., RHEL7) a menos que soluciona un problema específico que tiene con ext4, como sistemas de archivos con una capacidad de>50 TiB.
XFS no es de ninguna manera un sistema de archivos de "próxima generación" en la forma en que lo son ZFS, btrfs o incluso WAFL (un sistema de archivos SAN patentado). Al igual que ext4, lo más probable es que se considere un recurso provisional en el camino hacia algo mejor.
ZFS
ZFS fue desarrollado por Sun Microsystems y recibió su nombre del zettabyte, equivalente a 1 billón de gigabytes, ya que teóricamente podría abordar sistemas de almacenamiento de ese tamaño.
Un verdadero sistema de archivos de última generación, ZFS ofrece administración de volumen (la capacidad de abordar varios dispositivos de almacenamiento individuales en un solo sistema de archivos), suma de verificación criptográfica a nivel de bloque (permitiendo la detección de daños en los datos con una tasa de precisión extremadamente alta), reparación automática de daños (donde almacenamiento redundante o de paridad disponible), replicación incremental asíncrona rápida, compresión en línea y más. Mucho más.
El mayor problema con ZFS, desde la perspectiva de un usuario de Linux, es la licencia. ZFS obtuvo la licencia CDDL, que es una licencia semipermisiva que entra en conflicto con la GPL. Hay mucha controversia sobre las implicaciones de usar ZFS con el kernel de Linux, con opiniones que van desde "es una violación de GPL" a "es una violación de CDDL" a "está perfectamente bien, simplemente no ha sido probado en la corte. " En particular, Canonical ha incluido el código ZFS en línea en sus kernels predeterminados desde 2016 sin impugnación legal hasta el momento.
En este momento, incluso como muy Soy un ávido usuario de ZFS, no recomendaría ZFS como un sistema de archivos raíz de Linux. Si desea aprovechar los beneficios de ZFS en Linux, configure un pequeño sistema de archivos raíz en ext4, luego coloque ZFS en su almacenamiento restante y coloque datos, aplicaciones, lo que quiera en él, pero mantenga la raíz en ext4, hasta que su distribución explícitamente
btrfs
Btrfs, abreviatura de B-Tree Filesystem y generalmente pronunciado "mantequilla", fue anunciado por Chris Mason en 2007 durante su mandato en Oracle. Btrfs apunta a la mayoría de los mismos objetivos que ZFS, ofreciendo administración de múltiples dispositivos, suma de verificación por bloque, replicación asíncrona, compresión en línea y más.
A partir de 2018, btrfs es razonablemente estable y utilizable como un sistema de archivos estándar de un solo disco, pero probablemente no se deba confiar en él como administrador de volumen. Sufre de problemas de rendimiento significativos en comparación con ext4, XFS o ZFS en muchos casos de uso comunes, y sus funciones de próxima generación (replicación, topologías de discos múltiples y administración de instantáneas) pueden tener bastantes errores, con resultados que van desde un rendimiento catastróficamente reducido a la pérdida real de datos.
El estado actual de btrfs es controvertido; SUSE Enterprise Linux lo adoptó como su sistema de archivos predeterminado en 2015, mientras que Red Hat anunció que ya no admitiría btrfs a partir de RHEL 7.4 en 2017. Probablemente valga la pena señalar que las implementaciones compatibles y de producción de btrfs lo usan como un sistema de archivos de disco único, no como administrador de volumen de varios discos a la ZFS, incluso Synology, que usa btrfs en sus dispositivos de almacenamiento, pero lo superpone sobre RAID del kernel de Linux convencional (mdraid) para administrar los discos.