ZFS

ZFS (anteriormente Zettabyte File System ) es un sistema de archivos con capacidades de gestión de volúmenes . Comenzó como parte del sistema operativo Solaris de Sun Microsystems en 2001. Grandes partes de Solaris, incluido ZFS, se publicaron bajo una licencia de código abierto como OpenSolaris durante unos 5 años a partir de 2005 antes de colocarse bajo una licencia de código cerrado cuando Oracle Corporation adquirió Sun en 2009-2010. Durante 2005 a 2010, la versión de código abierto de ZFS se trasladó a Linux , Mac OS X (continuó como MacZFS ) y FreeBSD . En 2010, el proyecto illumos bifurcó una versión reciente de OpenSolaris, incluido ZFS, para continuar su desarrollo como un proyecto de código abierto. En 2013, se fundó OpenZFS para coordinar el desarrollo de ZFS de código abierto. ^{[3] [4] [5]} OpenZFS mantiene y administra el código central de ZFS, mientras que las organizaciones que utilizan ZFS mantienen el código específico y los procesos de validación necesarios para que ZFS se integre en sus sistemas. OpenZFS se utiliza ampliamente en sistemas tipo Unix . ^{[6] [7] [8]}

La gestión de datos almacenados generalmente implica dos aspectos: la gestión del volumen físico de uno o más dispositivos de almacenamiento en bloque (como discos duros y tarjetas SD ), incluida su organización en dispositivos de bloque lógicos como VDEV (dispositivo virtual ZFS) ^[9] como lo ve el sistema operativo (que a menudo implica un administrador de volumen , un controlador RAID , un administrador de matriz o un controlador de dispositivo adecuado ); y la gestión de datos y archivos que se almacenan en estos dispositivos de bloque lógicos (un sistema de archivos u otro almacenamiento de datos).

Ejemplo: una matriz RAID de 2 discos duros y un disco de caché SSD está controlada por el sistema RST de Intel , parte del chipset y el firmware integrado en una computadora de escritorio. El usuario de Windows ve esto como un solo volumen, que contiene una unidad con formato NTFS de sus datos, y NTFS no necesariamente es consciente de las manipulaciones que pueden ser necesarias (como leer desde/escribir en la unidad de caché o reconstruir la matriz RAID si falla un disco). La administración de los dispositivos individuales y su presentación como un solo dispositivo es distinta de la administración de los archivos almacenados en ese dispositivo aparente.

ZFS es inusual porque, a diferencia de la mayoría de los otros sistemas de almacenamiento, unifica ambos roles y actúa como administrador de volúmenes y sistema de archivos . Por lo tanto, tiene conocimiento completo tanto de los discos físicos como de los volúmenes (incluido su estado, condición y disposición lógica en volúmenes), así como de todos los archivos almacenados en ellos. ZFS está diseñado para garantizar (sujeto a hardware adecuado ) que los datos almacenados en los discos no se puedan perder debido a errores físicos, procesamiento incorrecto por parte del hardware o el sistema operativo , o eventos de pérdida de bits y corrupción de datos que pueden ocurrir con el tiempo. Su control completo del sistema de almacenamiento se utiliza para garantizar que cada paso, ya sea relacionado con la administración de archivos o la administración de discos , se verifique, confirme, corrija si es necesario y optimice, de una manera que las tarjetas controladoras de almacenamiento y los sistemas de archivos y volúmenes separados no pueden lograr.

ZFS también incluye un mecanismo para instantáneas y replicación a nivel de conjunto de datos y grupo , incluida la clonación de instantáneas , que se describe en la documentación de FreeBSD como una de sus "características más poderosas" con una funcionalidad de la que "incluso otros sistemas de archivos con funcionalidad de instantáneas carecen". ^[10] Se pueden tomar grandes cantidades de instantáneas sin degradar el rendimiento, lo que permite utilizarlas antes de operaciones de sistema riesgosas y cambios de software, o tomar instantáneas completas de un sistema de archivos de producción ("en vivo") varias veces por hora para mitigar la pérdida de datos debido a errores del usuario o actividad maliciosa. Las instantáneas se pueden revertir "en vivo" o se pueden ver estados anteriores del sistema de archivos, incluso en sistemas de archivos muy grandes, lo que genera ahorros en comparación con los procesos formales de copia de seguridad y restauración. ^[10] Las instantáneas también se pueden clonar para formar nuevos sistemas de archivos independientes. ZFS también tiene la capacidad de tomar una instantánea a nivel de grupo (conocida como "punto de control"), que permite revertir operaciones que pueden afectar la estructura de todo el grupo o que agregan o eliminan conjuntos de datos completos.

En 1987, AT&T Corporation y Sun anunciaron que estaban colaborando en un proyecto para fusionar las variantes de Unix más populares en el mercado en ese momento: Berkeley Software Distribution , UNIX System V y Xenix . Esto se convirtió en Unix System V Release 4 (SVR4). ^[11] El proyecto fue lanzado bajo el nombre de Solaris , que se convirtió en el sucesor de SunOS 4 (aunque las microversiones de SunOS 4.1. x se denominaron retroactivamente Solaris 1 ). ^[12]

ZFS fue diseñado e implementado por un equipo de Sun dirigido por Jeff Bonwick , Bill Moore, ^[13] y Matthew Ahrens. Fue anunciado el 14 de septiembre de 2004, ^[14] pero el desarrollo comenzó en 2001. ^[15] El código fuente de ZFS se integró en el tronco principal de desarrollo de Solaris el 31 de octubre de 2005 ^[16] y se publicó para desarrolladores como parte de la compilación 27 de OpenSolaris el 16 de noviembre de 2005. En junio de 2006, Sun anunció que ZFS se incluyó en la actualización principal 6/06 de Solaris 10. [ ^17]

Solaris fue desarrollado originalmente como software propietario , pero Sun Microsystems fue uno de los primeros en proponer comercialmente el software de código abierto y en junio de 2005 publicó la mayor parte del código base de Solaris bajo la licencia CDDL y fundó el proyecto de código abierto OpenSolaris . ^[18] En Solaris 10 6/06 ("U2"), Sun agregó el sistema de archivos ZFS y actualizó ZFS con frecuencia con nuevas características durante los siguientes 5 años. ZFS fue portado a Linux , Mac OS X (continuó como MacZFS ) y FreeBSD , bajo esta licencia de código abierto.

En un momento se dijo que el nombre significaba "Sistema de archivos Zettabyte", ^[19] pero en 2006, el nombre ya no se consideraba una abreviatura. ^[20] Un sistema de archivos ZFS puede almacenar hasta 256 cuatrillones de zettabytes (ZB).

En septiembre de 2007, NetApp demandó a Sun, alegando que ZFS infringía algunas de las patentes de NetApp sobre Write Anywhere File Layout . Sun presentó una contrademanda en octubre del mismo año alegando lo contrario. Las demandas finalizaron en 2010 con un acuerdo no revelado. ^[21]

Las versiones portadas de ZFS comenzaron a aparecer en 2005. Después de la adquisición de Sun por Oracle en 2010, la versión de ZFS de Oracle pasó a ser de código cerrado y el desarrollo de versiones de código abierto procedió de forma independiente, coordinado por OpenZFS a partir de 2013.

Algunos ejemplos de características específicas de ZFS incluyen:

• Diseñado para el almacenamiento de datos a largo plazo y tamaños de almacén de datos escalables indefinidamente con pérdida de datos cero y alta configurabilidad.
• Suma de comprobación jerárquica de todos los datos y metadatos , lo que garantiza que todo el sistema de almacenamiento se pueda verificar en uso y confirmar que se almacenó correctamente o se reparó si estaba dañado. Las sumas de comprobación se almacenan con el bloque padre de un bloque , en lugar de con el bloque en sí. Esto contrasta con muchos sistemas de archivos donde las sumas de comprobación (si se conservan) se almacenan con los datos, de modo que si los datos se pierden o se corrompen, es probable que la suma de comprobación también se pierda o sea incorrecta.
• Puede almacenar una cantidad especificada por el usuario de copias de datos o metadatos, o tipos de datos seleccionados, para mejorar la capacidad de recuperación de archivos y estructuras importantes en caso de corrupción de datos.
• Reversión automática de cambios recientes en el sistema de archivos y datos, en algunas circunstancias, en caso de error o inconsistencia.
• Autocuración automática y (normalmente) silenciosa de inconsistencias de datos y errores de escritura cuando se detectan, para todos los errores en los que los datos se pueden reconstruir. Los datos se pueden reconstruir utilizando todo lo siguiente: sumas de comprobación de detección y corrección de errores almacenadas en el bloque padre de cada bloque; múltiples copias de datos (incluidas las sumas de comprobación) guardadas en el disco; intenciones de escritura registradas en el SLOG (ZIL) para escrituras que deberían haberse producido pero no ocurrieron (después de un corte de energía); datos de paridad de discos y volúmenes RAID/RAID-Z; copias de datos de discos y volúmenes reflejados.
• Manejo nativo de niveles RAID estándar y diseños RAID ZFS adicionales ("RAID-Z"). Los niveles RAID-Z distribuyen los datos solo en los discos necesarios para lograr eficiencia (muchos sistemas RAID distribuyen los datos indiscriminadamente en todos los dispositivos) y la suma de comprobación permite minimizar la reconstrucción de datos inconsistentes o dañados en aquellos bloques con defectos;
• Manejo nativo de dispositivos de almacenamiento en caché y almacenamiento por niveles, que generalmente es una tarea relacionada con el volumen. Debido a que ZFS también comprende el sistema de archivos, puede usar el conocimiento relacionado con los archivos para informar, integrar y optimizar su manejo de almacenamiento por niveles, algo que un dispositivo independiente no puede hacer;
• Manejo nativo de instantáneas y copias de seguridad/ replicación que se puede hacer más eficiente mediante la integración del manejo de archivos y volúmenes. Las herramientas relevantes se proporcionan a bajo nivel y requieren scripts y software externos para su uso.
• Compresión y deduplicación de datos nativa , aunque esta última se gestiona en gran medida en RAM y consume mucha memoria.
• Reconstrucción eficiente de matrices RAID: un controlador RAID a menudo tiene que reconstruir un disco entero, pero ZFS puede combinar el conocimiento del disco y del archivo para limitar cualquier reconstrucción a los datos que realmente faltan o están dañados, acelerando enormemente la reconstrucción;
• No se ve afectado por los cambios de hardware RAID que afectan a muchos otros sistemas. En muchos sistemas, si falla un hardware RAID autónomo, como una tarjeta RAID, o si los datos se trasladan a otro sistema RAID, el sistema de archivos carecerá de la información que se encontraba en el hardware RAID original, que es necesaria para administrar los datos en la matriz RAID. Esto puede provocar una pérdida total de datos, a menos que se pueda adquirir un hardware casi idéntico y utilizarlo como "trampolín". Dado que ZFS administra RAID por sí mismo, se puede migrar un grupo de ZFS a otro hardware o se puede reinstalar el sistema operativo, y ZFS reconocerá las estructuras y los datos RAID-Z y volverá a tener acceso a ellos inmediatamente.
• Capacidad de identificar datos que se habrían encontrado en un caché pero que se descartaron recientemente; esto permite a ZFS reevaluar sus decisiones de almacenamiento en caché a la luz del uso posterior y facilita niveles muy altos de aciertos en caché (las tasas de aciertos en caché de ZFS suelen ser superiores al 80%);
• Se pueden utilizar estrategias de almacenamiento en caché alternativas para datos que, de otro modo, causarían demoras en el manejo de datos. Por ejemplo, las escrituras sincrónicas que pueden ralentizar el sistema de almacenamiento se pueden convertir en escrituras asincrónicas al escribirse en un dispositivo de almacenamiento en caché rápido e independiente, conocido como SLOG (a veces llamado ZIL, registro de intenciones de ZFS).
• Altamente ajustable: muchos parámetros internos se pueden configurar para una funcionalidad óptima.
• Se puede utilizar para clústeres y computación de alta disponibilidad , aunque no está totalmente diseñado para este uso.

Una característica importante que distingue a ZFS de otros sistemas de archivos es que está diseñado con un enfoque en la integridad de los datos al proteger los datos del usuario en el disco contra la corrupción silenciosa de datos causada por la degradación de datos , subidas de tensión ( picos de voltaje ), errores en el firmware del disco , escrituras fantasmas (la escritura anterior no llegó al disco), lecturas/escrituras mal dirigidas (el disco accede al bloque equivocado), errores de paridad DMA entre la matriz y la memoria del servidor o del controlador (ya que la suma de comprobación valida los datos dentro de la matriz), errores del controlador (los datos terminan en el búfer equivocado dentro del kernel), sobrescrituras accidentales (como el intercambio a un sistema de archivos en vivo), etc.

Un estudio de 1999 mostró que ni ninguno de los sistemas de archivos principales y generalizados en ese momento (como UFS , Ext , ^[22] XFS , JFS o NTFS ), ni el RAID de hardware (que tiene algunos problemas con la integridad de los datos ) proporcionaban suficiente protección contra problemas de corrupción de datos. ^{[23] [24] [25] [26]} La investigación inicial indica que ZFS protege los datos mejor que los esfuerzos anteriores. ^{[27] [28]} También es más rápido que UFS ^{[29] [30]} y puede considerarse como su reemplazo.

Dentro de ZFS, la integridad de los datos se logra mediante el uso de una suma de comprobación basada en Fletcher o un hash SHA-256 en todo el árbol del sistema de archivos. ^[31] Cada bloque de datos se suma de comprobación y el valor de la suma de comprobación se guarda en el puntero a ese bloque, en lugar de en el bloque real en sí. A continuación, se suma de comprobación al puntero del bloque, y el valor se guarda en su puntero. Esta suma de comprobación continúa hasta el nodo raíz de la jerarquía de datos del sistema de archivos, al que también se suma de comprobación, creando así un árbol Merkle . ^[31] La corrupción de datos en tránsito o las lecturas/escrituras fantasma (los datos escritos/leídos suman la comprobación correctamente pero en realidad son incorrectos) son indetectables para la mayoría de los sistemas de archivos, ya que almacenan la suma de comprobación con los datos. ZFS almacena la suma de comprobación de cada bloque en su puntero de bloque padre para que todo el grupo se autovalide. ^[31]

Cuando se accede a un bloque, independientemente de si se trata de datos o metadatos, se calcula su suma de comprobación y se compara con el valor de suma de comprobación almacenado de lo que "debería" ser. Si las sumas de comprobación coinciden, los datos se pasan a la pila de programación al proceso que los solicitó; si los valores no coinciden, ZFS puede reparar los datos si el grupo de almacenamiento proporciona redundancia de datos (como con duplicación interna ), suponiendo que la copia de datos no está dañada y con sumas de comprobación coincidentes. ^[32] Opcionalmente, es posible proporcionar redundancia adicional en el grupo especificando copies=2 (o copies=3 ), lo que significa que los datos se almacenarán dos veces (o tres veces) en el disco, lo que efectivamente reduce a la mitad (o, para copies=3 , reduce a un tercio) la capacidad de almacenamiento del disco. ^[33] Además, algunos tipos de datos utilizados por ZFS para administrar el grupo se almacenan varias veces de forma predeterminada para mayor seguridad, incluso con la configuración predeterminada copies=1.

Si existen otras copias de los datos dañados o se pueden reconstruir a partir de las sumas de comprobación y los datos de paridad , ZFS utilizará una copia de los datos (o los recreará mediante un mecanismo de recuperación RAID) y volverá a calcular la suma de comprobación, lo que idealmente dará como resultado la reproducción del valor esperado originalmente. Si los datos pasan esta comprobación de integridad, el sistema puede actualizar todas las copias defectuosas con datos que se sabe que son correctos y se restaurará la redundancia.

Si no hay copias de los datos dañados, ZFS pone el grupo en un estado de falla, ^[34] impidiendo su uso futuro y no brindando formas documentadas de recuperar el contenido del grupo.

La coherencia de los datos almacenados en la memoria, como los datos almacenados en caché en el ARC, no se verifica de forma predeterminada, ya que se espera que ZFS se ejecute en hardware de calidad empresarial con RAM con corrección de errores . Sin embargo, existe la capacidad de verificar los datos en la memoria y se puede habilitar mediante "indicadores de depuración". ^[35]

Para que ZFS pueda garantizar la integridad de los datos, necesita varias copias de los datos, normalmente distribuidas en varios discos. Esto se consigue normalmente utilizando un controlador RAID o el denominado RAID "suave" (integrado en un sistema de archivos ).

Si bien ZFS puede funcionar con dispositivos RAID de hardware , generalmente funcionará de manera más eficiente y con mayor protección de datos si tiene acceso sin formato a todos los dispositivos de almacenamiento. ZFS se basa en el disco para obtener una visión honesta para determinar el momento en que se confirma que los datos se escribieron de manera segura y tiene numerosos algoritmos diseñados para optimizar su uso del almacenamiento en caché , el vaciado de caché y el manejo del disco.

Los discos conectados al sistema mediante hardware, firmware, otro RAID "suave" o cualquier otro controlador que modifique la ruta de E/S de ZFS a disco afectarán el rendimiento de ZFS y la integridad de los datos. Si un dispositivo de terceros realiza el almacenamiento en caché o presenta las unidades a ZFS como un sistema único sin la vista de bajo nivel en la que se basa ZFS, existe una probabilidad mucho mayor de que el sistema funcione de manera menos óptima y de que ZFS tenga menos probabilidades de evitar fallas, recuperarse de fallas más lentamente o perder datos debido a una falla de escritura. Por ejemplo, si se utiliza una tarjeta RAID de hardware, es posible que ZFS no pueda determinar la condición de los discos, determinar si la matriz RAID está degradada o en reconstrucción, detectar todos los datos dañados, colocar los datos de manera óptima en los discos, realizar reparaciones selectivas, controlar cómo se equilibran las reparaciones con el uso continuo o realizar reparaciones que ZFS normalmente podría realizar. La tarjeta RAID de hardware interferirá con los algoritmos de ZFS. Los controladores RAID también suelen agregar datos dependientes del controlador a las unidades, lo que evita que el RAID de software acceda a los datos del usuario. En caso de falla de un controlador RAID de hardware, es posible leer los datos con otro controlador compatible, pero esto no siempre es posible y es posible que no haya un reemplazo disponible. Es posible que los controladores RAID de hardware alternativos no comprendan los datos personalizados del fabricante original necesarios para administrar y restaurar una matriz.

A diferencia de la mayoría de los otros sistemas donde las tarjetas RAID o hardware similar pueden descargar recursos y procesamiento para mejorar el rendimiento y la confiabilidad, con ZFS se recomienda enfáticamente no utilizar estos métodos, ya que generalmente reducen el rendimiento y la confiabilidad del sistema.

Si los discos deben conectarse a través de un RAID u otro controlador, se recomienda minimizar la cantidad de procesamiento realizado en el controlador mediante el uso de un HBA (adaptador de host) simple , una tarjeta de distribución simple o configurar la tarjeta en modo JBOD (es decir, desactivar las funciones RAID y de almacenamiento en caché), para permitir que los dispositivos se conecten con cambios mínimos en la ruta de E/S de ZFS a disco. Una tarjeta RAID en modo JBOD aún puede interferir si tiene un caché o, según su diseño, puede desconectar unidades que no responden a tiempo (como se ha visto con muchos discos duros de consumo de bajo consumo energético) y, como tal, puede requerir unidades habilitadas para recuperación de errores limitada en el tiempo (TLER)/CCTL/ERC para evitar desconexiones de la unidad, por lo que no todas las tarjetas son adecuadas incluso con las funciones RAID deshabilitadas. ^[36]

En lugar de RAID de hardware, ZFS emplea RAID "suave", que ofrece RAID-Z ( basado en paridad , como RAID 5 y similares) y duplicación de discos (similar a RAID 1 ). Los esquemas son muy flexibles.

RAID-Z es un esquema de distribución de datos/paridad como RAID-5 , pero utiliza ancho de banda dinámico: cada bloque es su propia banda RAID, independientemente del tamaño del bloque, lo que da como resultado que cada escritura RAID-Z sea una escritura de banda completa. Esto, cuando se combina con la semántica transaccional de copia en escritura de ZFS, elimina el error de agujero de escritura . RAID-Z también es más rápido que el RAID 5 tradicional porque no necesita realizar la secuencia habitual de lectura-modificación-escritura . ^[37]

Como todas las bandas son de tamaños diferentes, la reconstrucción RAID-Z tiene que recorrer los metadatos del sistema de archivos para determinar la geometría RAID-Z real. Esto sería imposible si el sistema de archivos y la matriz RAID fueran productos separados, mientras que se vuelve factible cuando hay una vista integrada de la estructura lógica y física de los datos. El recorrido por los metadatos significa que ZFS puede validar cada bloque contra su suma de comprobación de 256 bits a medida que avanza, mientras que los productos RAID tradicionales por lo general no pueden hacer esto. ^[37]

Además de gestionar fallos de todo el disco, RAID-Z también puede detectar y corregir la corrupción silenciosa de datos , ofreciendo "datos de autorreparación": al leer un bloque RAID-Z, ZFS lo compara con su suma de comprobación y, si los discos de datos no devolvieron la respuesta correcta, ZFS lee la paridad y luego determina qué disco devolvió datos incorrectos. Luego, repara los datos dañados y devuelve los datos correctos al solicitante. ^[37]

RAID-Z y la duplicación no requieren ningún hardware especial: no necesitan NVRAM para ser confiables y no necesitan almacenamiento en búfer de escritura para un buen rendimiento o protección de datos. Con RAID-Z, ZFS proporciona almacenamiento rápido y confiable utilizando discos económicos y de consumo masivo. ^{[ ¿promoción? ] [37]}

Hay cinco modos RAID-Z diferentes: striping (similar a RAID 0, no ofrece redundancia), RAID-Z1 (similar a RAID 5, permite que falle un disco), RAID-Z2 (similar a RAID 6, permite que fallen dos discos), RAID-Z3 (una configuración RAID 7 ^[a] , permite que fallen tres discos) y duplicación (similar a RAID 1, permite que fallen todos los discos menos uno). ^[39]

La necesidad de RAID-Z3 surgió a principios de la década de 2000, cuando las unidades con capacidad de varios terabytes se hicieron más comunes. Este aumento de la capacidad (sin un aumento correspondiente en las velocidades de procesamiento) significaba que la reconstrucción de una matriz debido a una unidad defectuosa podía "tomar fácilmente semanas o meses" en completarse. ^[38] Durante este tiempo, los discos más antiguos de la matriz se verán sometidos a una carga de trabajo adicional, lo que podría provocar la corrupción de datos o la falla de la unidad. Al aumentar la paridad, RAID-Z3 reduce la posibilidad de pérdida de datos simplemente aumentando la redundancia. ^[40]

ZFS no tiene una herramienta equivalente a fsck (la herramienta estándar de verificación y reparación de datos de Unix y Linux para sistemas de archivos). ^{[41] En cambio, ZFS tiene una función} de limpieza incorporada que examina regularmente todos los datos y repara la corrupción silenciosa y otros problemas. Algunas diferencias son:

• fsck debe ejecutarse en un sistema de archivos fuera de línea, lo que significa que el sistema de archivos debe estar desmontado y no se puede utilizar mientras se repara, mientras que scrub está diseñado para usarse en un sistema de archivos montado y activo, y no necesita que el sistema de archivos ZFS esté fuera de línea.
• Por lo general, fsck solo verifica metadatos (como el registro diario), pero nunca verifica los datos en sí. Esto significa que, después de un fsck, los datos podrían no coincidir con los datos originales tal como estaban almacenados.
• fsck no siempre puede validar y reparar datos cuando las sumas de comprobación se almacenan con los datos (que suele ser el caso en muchos sistemas de archivos), porque las sumas de comprobación también pueden estar dañadas o ser ilegibles. ZFS siempre almacena las sumas de comprobación por separado de los datos que verifica, lo que mejora la confiabilidad y la capacidad de scrub para reparar el volumen. ZFS también almacena múltiples copias de datos; los metadatos, en particular, pueden tener más de 4 o 6 copias (múltiples copias por disco y múltiples espejos de disco por volumen), lo que mejora en gran medida la capacidad de scrub para detectar y reparar daños extensos al volumen, en comparación con fsck.
• scrub comprueba todo, incluidos los metadatos y los datos. El efecto se puede observar comparando los tiempos de fsck con scrub: a veces, un fsck en un RAID grande se completa en unos pocos minutos, lo que significa que solo se comprobaron los metadatos. Recorrer todos los metadatos y datos en un RAID grande lleva muchas horas, que es exactamente lo que hace scrub.
• Mientras que fsck detecta y trata de corregir errores utilizando los datos disponibles del sistema de archivos, scrub se basa en la redundancia para recuperarse de los problemas. Mientras que fsck ofrece reparar el sistema de archivos con pérdida parcial de datos, scrub lo pone en estado de falla si no hay redundancia. ^[34]

La recomendación oficial de Sun/Oracle es limpiar los discos de nivel empresarial una vez al mes y los discos de consumo más económicos una vez a la semana. ^{[42] [43]}

ZFS es un sistema de archivos de 128 bits , ^{[44] [16]} por lo que puede manejar 1,84 × 10 ¹⁹ veces más datos que los sistemas de 64 bits como Btrfs . Los límites máximos de ZFS están diseñados para ser tan grandes que nunca deberían encontrarse en la práctica. Por ejemplo, para llenar por completo un solo zpool con 2 ¹²⁸ bits de datos se necesitarían 3 × 10  unidades de disco duro de ^{24 TB. [45]}

Algunos límites teóricos en ZFS son:

• 16 exbibytes (2 ⁶⁴ bytes): tamaño máximo de un solo archivo
• 2 ⁴⁸ : número de entradas en cualquier directorio individual ^[46]
• 16 exbibytes: tamaño máximo de cualquier atributo
• 2 ⁵⁶ : número de atributos de un archivo (en realidad, limitado a 2 ⁴⁸ para la cantidad de archivos en un directorio)
• 256 cuatrillones de zebibytes (2128 ^bytes ): tamaño máximo de cualquier zpool
• 2 ⁶⁴ : número de dispositivos en cualquier zpool
• 2 ⁶⁴ : número de sistemas de archivos en un zpool
• 2 ⁶⁴ : número de zpools en un sistema

Con Oracle Solaris, la capacidad de cifrado en ZFS ^[47] está integrada en el flujo de E/S. Durante las escrituras, un bloque puede comprimirse, cifrarse, sumarse y luego deduplicarse, en ese orden. La política de cifrado se establece en el nivel de conjunto de datos cuando se crean conjuntos de datos (sistemas de archivos o ZVOL). Las claves de encapsulamiento proporcionadas por el usuario/administrador se pueden cambiar en cualquier momento sin desconectar el sistema de archivos. El comportamiento predeterminado es que la clave de encapsulamiento sea heredada por cualquier conjunto de datos secundario. Las claves de cifrado de datos se generan aleatoriamente en el momento de la creación del conjunto de datos. Solo los conjuntos de datos descendientes (instantáneas y clones) comparten claves de cifrado de datos. ^[48] Se proporciona un comando para cambiar a una nueva clave de cifrado de datos para el clon o en cualquier momento; esto no vuelve a cifrar los datos ya existentes, sino que utiliza un mecanismo de clave maestra cifrada.

A partir de 2019, ^[update]la función de cifrado también está completamente integrada en OpenZFS 0.8.0 disponible para distribuciones Debian y Ubuntu Linux. ^[49]

Se han recibido informes anecdóticos de usuarios finales sobre fallos al utilizar el cifrado nativo de ZFS. No se ha establecido una causa exacta. ^{[50] [51]}

ZFS asignará automáticamente el almacenamiento de datos entre todos los dispositivos virtuales de un pool (y todos los dispositivos de cada uno de ellos) de forma que, en general, se maximice el rendimiento del pool. ZFS también actualizará su estrategia de escritura para tener en cuenta los nuevos discos que se agreguen a un pool, cuando se agreguen.

Como regla general, ZFS asigna escrituras entre los vdevs en función del espacio libre en cada uno de ellos. Esto garantiza que los vdevs que ya tienen proporcionalmente menos datos reciban más escrituras cuando se deben almacenar nuevos datos. Esto ayuda a garantizar que, a medida que el pool se utiliza más, no se produzca la situación de que algunos vdevs se llenen, lo que obliga a que las escrituras se realicen en una cantidad limitada de dispositivos. También significa que cuando se leen datos (y las lecturas son mucho más frecuentes que las escrituras en la mayoría de los usos), se pueden leer diferentes partes de los datos desde tantos discos como sea posible al mismo tiempo, lo que brinda un rendimiento de lectura mucho mayor. Por lo tanto, como regla general, se deben administrar los pools y los vdevs y agregar nuevo almacenamiento, de modo que no surja la situación de que algunos vdevs en un pool estén casi llenos y otros casi vacíos, ya que esto hará que el pool sea menos eficiente.

El espacio libre en ZFS tiende a fragmentarse con el uso. ZFS no tiene un mecanismo para desfragmentar el espacio libre. Hay informes anecdóticos de usuarios finales que indican una disminución del rendimiento cuando la alta fragmentación del espacio libre se combina con una sobreutilización del espacio en disco. ^{[52] [53]}

Los grupos pueden tener repuestos activos para compensar las fallas de los discos. Al realizar la duplicación, los dispositivos de bloque se pueden agrupar según el chasis físico, de modo que el sistema de archivos pueda continuar en caso de falla de un chasis completo.

La composición de un grupo de almacenamiento no se limita a dispositivos similares, sino que puede consistir en conjuntos heterogéneos de dispositivos ad hoc que ZFS agrupa sin problemas y, posteriormente, distribuye espacio entre conjuntos de datos (instancias del sistema de archivos o ZVOL) según sea necesario. Se pueden agregar tipos arbitrarios de dispositivos de almacenamiento a los grupos existentes para ampliar su tamaño. ^[54]

La capacidad de almacenamiento de todos los vdevs está disponible para todas las instancias del sistema de archivos en el zpool. Se puede establecer una cuota para limitar la cantidad de espacio que puede ocupar una instancia del sistema de archivos y se puede establecer una reserva para garantizar que haya espacio disponible para una instancia del sistema de archivos.

ZFS utiliza diferentes capas de caché de disco para acelerar las operaciones de lectura y escritura. Lo ideal sería que todos los datos se almacenaran en la RAM, pero eso suele ser demasiado caro. Por lo tanto, los datos se almacenan automáticamente en caché en una jerarquía para optimizar el rendimiento en relación con el costo; ^[55] a menudo se los llama "grupos de almacenamiento híbridos". ^[56] Los datos a los que se accede con frecuencia se almacenarán en la RAM, y los datos a los que se accede con menos frecuencia se pueden almacenar en medios más lentos, como unidades de estado sólido (SSD). Los datos a los que no se accede con frecuencia no se almacenan en caché y se dejan en los discos duros lentos. Si de repente se leen muchos datos antiguos, ZFS los moverá automáticamente a las SSD o a la RAM.

Los mecanismos de almacenamiento en caché de ZFS incluyen uno para lectura y otro para escritura, y en cada caso pueden existir dos niveles de almacenamiento en caché: uno en la memoria de la computadora (RAM) y otro en el almacenamiento rápido (normalmente unidades de estado sólido (SSD)), para un total de cuatro cachés.

También existen otros cachés, divisiones de caché y colas dentro de ZFS. Por ejemplo, cada VDEV tiene su propio caché de datos y el caché ARC se divide entre los datos almacenados por el usuario y los metadatos utilizados por ZFS, con control sobre el equilibrio entre estos.

En OpenZFS 0.8 y versiones posteriores, es posible configurar una clase VDEV especial para almacenar de manera preferencial metadatos del sistema de archivos y, opcionalmente, la tabla de deduplicación de datos (DDT) y pequeños bloques del sistema de archivos. ^[58] Esto permite, por ejemplo, crear una clase VDEV especial en un almacenamiento de estado sólido rápido para almacenar los metadatos, mientras que los datos de archivo regulares se almacenan en discos giratorios. Esto acelera las operaciones intensivas en metadatos, como el recorrido del sistema de archivos, la limpieza y la resilver, sin el gasto de almacenar todo el sistema de archivos en un almacenamiento de estado sólido.

ZFS utiliza un modelo de objeto transaccional de copia en escritura . Todos los punteros de bloque dentro del sistema de archivos contienen una suma de comprobación de 256 bits o un hash de 256 bits (actualmente una opción entre Fletcher-2 , Fletcher-4 o SHA-256 ) ^[59] del bloque de destino, que se verifica cuando se lee el bloque. Los bloques que contienen datos activos nunca se sobrescriben en su lugar; en cambio, se asigna un nuevo bloque, se escriben datos modificados en él y, a continuación, se leen, reasignan y escriben de forma similar todos los bloques de metadatos que hacen referencia a él. Para reducir la sobrecarga de este proceso, se agrupan varias actualizaciones en grupos de transacciones y se utiliza la caché de escritura ZIL ( registro de intenciones ) cuando se requiere semántica de escritura sincrónica. Los bloques se organizan en un árbol, al igual que sus sumas de comprobación (consulte el esquema de firma de Merkle ).

This section does not cite any sources. Please help improve this section by adding citations to reliable sources. Unsourced material may be challenged and removed. (January 2017) (Learn how and when to remove this message)

Una ventaja de la copia en escritura es que, cuando ZFS escribe datos nuevos, se pueden conservar los bloques que contienen los datos antiguos, lo que permite mantener una versión instantánea del sistema de archivos. Las instantáneas de ZFS son consistentes (reflejan todos los datos tal como existían en un único punto en el tiempo) y se pueden crear con extrema rapidez, ya que todos los datos que componen la instantánea ya están almacenados, y a menudo se toman instantáneas del conjunto de almacenamiento completo varias veces por hora. También son eficientes en términos de espacio, ya que los datos que no se modifican se comparten entre el sistema de archivos y sus instantáneas. Las instantáneas son inherentemente de solo lectura, lo que garantiza que no se modificarán después de su creación, aunque no se debe confiar en ellas como único medio de copia de seguridad. Se pueden restaurar instantáneas completas y también archivos y directorios dentro de ellas.

También se pueden crear instantáneas que se puedan escribir ("clones"), lo que da como resultado dos sistemas de archivos independientes que comparten un conjunto de bloques. A medida que se realizan cambios en cualquiera de los sistemas de archivos clonados, se crean nuevos bloques de datos para reflejar esos cambios, pero los bloques que no se modifican continúan compartiéndose, sin importar cuántos clones existan. Esta es una implementación del principio de copia en escritura .

This section does not cite any sources. Please help improve this section by adding citations to reliable sources. Unsourced material may be challenged and removed. (January 2017) (Learn how and when to remove this message)

Los sistemas de archivos ZFS se pueden mover a otros grupos, también en hosts remotos a través de la red, ya que el comando de envío crea una representación de flujo del estado del sistema de archivos. Este flujo puede describir el contenido completo del sistema de archivos en una instantánea determinada o puede ser un delta entre instantáneas. El cálculo del flujo delta es muy eficiente y su tamaño depende de la cantidad de bloques modificados entre las instantáneas. Esto proporciona una estrategia eficiente, por ejemplo, para sincronizar copias de seguridad externas o espejos de alta disponibilidad de un grupo.

La distribución dinámica en todos los dispositivos para maximizar el rendimiento significa que a medida que se agregan dispositivos adicionales al zpool, el ancho de la distribución se expande automáticamente para incluirlos; por lo tanto, se utilizan todos los discos en un pool, lo que equilibra la carga de escritura entre ellos. ^[60]

ZFS utiliza bloques de tamaño variable, siendo 128 KB el tamaño predeterminado. Las funciones disponibles permiten al administrador ajustar el tamaño máximo de bloque que se utiliza, ya que ciertas cargas de trabajo no funcionan bien con bloques grandes. Si la compresión de datos está habilitada, se utilizan tamaños de bloque variables. Si un bloque se puede comprimir para que quepa en un tamaño de bloque más pequeño, se utiliza el tamaño más pequeño en el disco para utilizar menos almacenamiento y mejorar el rendimiento de E/S (aunque a costa de un mayor uso de la CPU para las operaciones de compresión y descompresión). ^[61]

En ZFS, la manipulación del sistema de archivos dentro de un grupo de almacenamiento es más sencilla que la manipulación de volúmenes dentro de un sistema de archivos tradicional; el tiempo y el esfuerzo necesarios para crear o expandir un sistema de archivos ZFS son más parecidos a los que se requieren para crear un nuevo directorio que a los que se requieren para la manipulación de volúmenes en otros sistemas. ^{[ cita requerida ]}

This section does not cite any sources. Please help improve this section by adding citations to reliable sources. Unsourced material may be challenged and removed. (January 2017) (Learn how and when to remove this message)

Los grupos y sus sistemas de archivos ZFS asociados se pueden mover entre diferentes arquitecturas de plataforma, incluidos sistemas que implementan diferentes órdenes de bytes. El formato de puntero de bloque ZFS almacena metadatos del sistema de archivos de una manera adaptativa al orden de bytes ; los bloques de metadatos individuales se escriben con el orden de bytes nativo del sistema que escribe el bloque. Al leer, si el orden de bytes almacenado no coincide con el orden de bytes del sistema, los metadatos se intercambian en la memoria.

Esto no afecta los datos almacenados; como es habitual en los sistemas POSIX , los archivos aparecen para las aplicaciones como simples matrices de bytes, por lo que las aplicaciones que crean y leen datos siguen siendo responsables de hacerlo de una manera independiente del orden de bytes del sistema subyacente.

Las capacidades de deduplicación de datos se agregaron al repositorio de origen de ZFS a fines de octubre de 2009, ^[62] y los paquetes de desarrollo de OpenSolaris ZFS relevantes están disponibles desde el 3 de diciembre de 2009 (compilación 128).

El uso eficaz de la deduplicación puede requerir una gran capacidad de RAM; las recomendaciones varían entre 1 y 5 GB de RAM por cada TB de almacenamiento. ^{[63] [64] [65]} Una evaluación precisa de la memoria necesaria para la deduplicación se realiza haciendo referencia a la cantidad de bloques únicos en el grupo y la cantidad de bytes en el disco y en la RAM ("núcleo") necesarios para almacenar cada registro; estas cifras se informan mediante comandos integrados como zpooly zdb. La memoria física insuficiente o la falta de caché ZFS pueden provocar una pérdida de memoria virtual al usar la deduplicación, lo que puede hacer que el rendimiento se desplome o provocar una inanición total de la memoria. ^{[ cita requerida ]} Debido a que la deduplicación ocurre en el momento de la escritura, también consume mucha CPU y esto también puede ralentizar significativamente un sistema.

Otros proveedores de almacenamiento utilizan versiones modificadas de ZFS para lograr índices de compresión de datos muy elevados . Dos ejemplos en 2012 fueron GreenBytes ^{[66] y Tegile [67]} . En mayo de 2014, Oracle compró GreenBytes por su tecnología de deduplicación y replicación ZFS ^[68] .

Como se describió anteriormente, la deduplicación generalmente no se recomienda debido a sus grandes requisitos de recursos (especialmente RAM) y su impacto en el rendimiento (especialmente al escribir), excepto en circunstancias específicas en las que el sistema y los datos son adecuados para esta técnica de ahorro de espacio.

• Prioridad de E/S explícita con programación de fechas límite. ^{[ cita requerida ]}
• Se afirma que la ordenación y agregación de E/S son óptimas a nivel mundial. ^{[ cita requerida ]}
• Múltiples secuencias de precarga independientes con detección automática de longitud y paso. ^{[ cita requerida ]}
• Operaciones de directorio en paralelo y en tiempo constante. ^{[ cita requerida ]}
• Suma de comprobación de extremo a extremo, utilizando una especie de " Campo de integridad de datos ", que permite la detección de corrupción de datos (y su recuperación si se tiene redundancia en el pool). Se puede utilizar una selección de 3 hashes, optimizados para velocidad (fletcher), estandarización y seguridad ( SHA256 ) y hashes salados ( Skein ). ^[69]
• Compresión transparente del sistema de archivos. Admite LZJB , gzip , ^[70] LZ4 y Zstd .
• Fregado y replateado inteligente (resincronización). ^[71]
• Uso compartido de carga y espacio entre los discos del pool. ^[72]
• Bloques Ditto: replicación de datos configurable por sistema de archivos, con cero, una o dos copias adicionales solicitadas por escritura para datos de usuario, y con ese mismo número base de copias más una o dos para metadatos (según la importancia de los metadatos). ^[73] Si el grupo tiene varios dispositivos, ZFS intenta replicar en diferentes dispositivos. Los bloques Ditto son principalmente una protección adicional contra sectores dañados, no contra fallas totales del disco. ^[74]
• El diseño de ZFS (copia en escritura + superbloques) es seguro cuando se utilizan discos con caché de escritura habilitado, si respetan las barreras de escritura. ^{[ cita requerida ]} Esta característica proporciona seguridad y un aumento del rendimiento en comparación con otros sistemas de archivos. ^{[ ¿según quién? ]}
• En Solaris, cuando se agregan discos completos a un grupo ZFS, ZFS habilita automáticamente su caché de escritura. Esto no se hace cuando ZFS solo administra porciones discretas del disco, ya que no sabe si otras porciones son administradas por sistemas de archivos que no son seguros para la caché de escritura, como UFS . ^{[ cita requerida ]} La implementación de FreeBSD puede manejar vaciados de discos para particiones gracias a su marco GEOM y, por lo tanto, no sufre esta limitación. ^{[ cita requerida ]}
• Límites de cuota por usuario, por grupo, por proyecto y por conjunto de datos. ^[75]
• Cifrado del sistema de archivos desde Solaris 11 Express, ^[76] y OpenZFS (ZoL) 0.8. ^[58] (en algunos otros sistemas, ZFS puede utilizar discos cifrados para lograr un efecto similar; GELI en FreeBSD se puede utilizar de esta manera para crear almacenamiento ZFS completamente cifrado).
• Los grupos se pueden importar en modo de solo lectura.
• Es posible recuperar datos revirtiendo transacciones completas al momento de importar el zpool. ^{[ cita requerida ]}
• Las instantáneas se pueden tomar de forma manual o automática. Las versiones anteriores de los datos almacenados que contienen se pueden exponer como sistemas de archivos de solo lectura completos. También se pueden exponer como versiones históricas de archivos y carpetas cuando se utilizan con CIFS (también conocido como SMB, Samba o recursos compartidos de archivos); esto se conoce como "Versiones anteriores", "Copias de sombra VSS" o "Historial de archivos" en Windows , o AFP y "Apple Time Machine" en dispositivos Apple. ^[77]
• Los discos se pueden marcar como "de repuesto". Se puede configurar un grupo de datos para que gestione de forma automática y transparente las fallas de los discos activando un disco de repuesto y comenzando a reutilizar los datos que estaban en el disco sospechoso cuando sea necesario.

• A partir de Solaris 10 Update 11 y Solaris 11.2, no era posible reducir la cantidad de vdevs de nivel superior en un pool, excepto repuestos activos, caché y dispositivos de registro, ni reducir de otro modo la capacidad del pool. ^[78] Se dijo que esta funcionalidad estaba en desarrollo en 2007. ^[79] Se están desarrollando mejoras para permitir la reducción de vdevs en OpenZFS. ^[80] La reducción en línea mediante la eliminación de vdevs de nivel superior no redundantes se admite desde Solaris 11.4 lanzado en agosto de 2018 ^[81] y OpenZFS (ZoL) 0.8 lanzado en mayo de 2019. ^[58]
• A partir de 2008, ^[update]no era posible agregar un disco como columna a un vdev RAID Z, RAID Z2 o RAID Z3. Sin embargo, se puede crear un nuevo vdev RAID Z y agregarlo al zpool. ^[82]
• Algunas configuraciones RAID anidadas tradicionales, como RAID 51 (un espejo de grupos RAID 5), no se pueden configurar en ZFS sin algunas herramientas de terceros. ^[83] Los vdevs solo pueden estar compuestos de discos o archivos sin procesar, no otros vdevs, utilizando los comandos de administración ZFS predeterminados. ^[84] Sin embargo, un grupo ZFS crea efectivamente una franja (RAID 0) a través de sus vdevs, por lo que el equivalente a un RAID 50 o RAID 60 es común.
• Para reconfigurar la cantidad de dispositivos en un vdev de nivel superior es necesario copiar datos sin conexión, destruir el grupo y volver a crearlo con la nueva configuración de vdev de nivel superior, excepto para agregar redundancia adicional a un espejo existente, lo que se puede hacer en cualquier momento o si todos los vdev de nivel superior son espejos con suficiente redundancia, se puede usar el comando zpool split ^[85] para eliminar un vdev de cada vdev de nivel superior en el grupo, creando un segundo grupo con datos idénticos.

ZFS no incluye herramientas como fsck , porque el sistema de archivos en sí fue diseñado para autorrepararse. Mientras se haya creado un grupo de almacenamiento prestando suficiente atención al diseño del almacenamiento y la redundancia de los datos, nunca se han necesitado herramientas básicas como fsck . Sin embargo, si el grupo se veía comprometido debido a un hardware deficiente, un diseño o redundancia inadecuados o un contratiempo desafortunado, hasta el punto de que ZFS no podía montar el grupo, tradicionalmente no había otras herramientas más avanzadas que permitieran a un usuario final intentar recuperar parcialmente los datos almacenados de un grupo muy dañado.

El sistema ZFS moderno ha mejorado considerablemente esta situación con el tiempo y continúa haciéndolo:

• La eliminación o falla abrupta de los dispositivos de almacenamiento en caché ya no provoca la pérdida de un grupo. (En el peor de los casos, la pérdida de la ZIL puede hacer que se pierdan transacciones muy recientes, pero la ZIL no suele almacenar más que unos pocos segundos de transacciones recientes. La pérdida de la caché L2ARC no afecta a los datos).
• Si el grupo no se puede montar, las versiones modernas de ZFS intentarán identificar el punto coherente más reciente en el que se puede recuperar el grupo, a costa de perder algunos de los cambios más recientes en el contenido. La copia en escritura significa que las versiones anteriores de los datos, incluidos los registros de nivel superior y los metadatos, pueden seguir existiendo aunque se hayan reemplazado y, de ser así, el grupo puede volver a un estado coherente en función de ellos. Cuanto más antiguos sean los datos, más probable es que se hayan sobrescrito al menos algunos bloques y que algunos datos sean irrecuperables, por lo que existe un límite en algún punto en la capacidad del grupo para volver a un estado coherente.
• De manera informal, existen herramientas para investigar el motivo por el cual ZFS no puede montar un grupo y orientar al usuario o al desarrollador sobre los cambios manuales necesarios para forzar el montaje del grupo. Estos incluyen el uso de zdb (depuración de ZFS) para encontrar un punto importable válido en el grupo, el uso de dtrace o similar para identificar el problema que causa el error de montaje o la omisión manual de las comprobaciones de estado que hacen que el proceso de montaje se anule y permitir el montaje del grupo dañado.
• A partir de marzo de 2018 ^[update], se están implementando gradualmente en OpenZFS una serie de métodos significativamente mejorados, entre los que se incluyen: ^[86]

• Refactorización de código e información de diagnóstico y depuración más detallada sobre fallas de montaje, para simplificar el diagnóstico y la reparación de problemas de pool corruptos;
• La capacidad de confiar o no en la configuración del pool almacenada. Esto es particularmente poderoso, ya que permite montar un pool incluso cuando faltan vdevs de nivel superior o son defectuosos, cuando los datos de nivel superior son sospechosos y también retroceder más allá de un cambio de configuración del pool si ese cambio estaba relacionado con el problema. Una vez que se monta el pool dañado, se pueden copiar archivos legibles por seguridad y puede resultar que se puedan reconstruir los datos incluso para los vdevs faltantes, utilizando copias almacenadas en otra parte del pool.
• La capacidad de solucionar la situación en la que un disco necesario en un grupo se eliminaba accidentalmente y se agregaba a un grupo diferente, lo que provocaba la pérdida de metadatos relacionados con el primer grupo, que se volvía ilegible.

Oracle Corporation cesó el desarrollo público de ZFS y OpenSolaris después de la adquisición de Sun en 2010. Algunos desarrolladores bifurcaron la última versión pública de OpenSolaris como el proyecto Illumos. Debido a las importantes ventajas presentes en ZFS, se ha adaptado a varias plataformas diferentes con diferentes funciones y comandos. Para coordinar los esfuerzos de desarrollo y evitar la fragmentación, se fundó OpenZFS en 2013.

Según Matt Ahrens, uno de los principales arquitectos de ZFS, más del 50% del código original de OpenSolaris ZFS ha sido reemplazado en OpenZFS con contribuciones de la comunidad a partir de 2019, lo que hace que “Oracle ZFS” y “OpenZFS” sean política y tecnológicamente incompatibles. ^[87]

• 2008: Sun lanzó una línea de dispositivos de almacenamiento de la serie 7000 basados ​​en ZFS. ^[88]
• 2013: Oracle lanzó la serie ZS3 de archivadores basados ​​en ZFS y obtuvo el primer lugar en el benchmark SPC-2 con uno de ellos. ^[89]
• 2013: iXsystems envía dispositivos NAS basados ​​en ZFS llamados FreeNAS (ahora llamados TrueNAS CORE) para SOHO y TrueNAS para empresas. ^{[90] [91]}
• 2014: Netgear lanza una línea de dispositivos NAS basados ​​en ZFS llamados ReadyDATA , diseñados para ser utilizados en la empresa. ^[92]
• 2015: rsync.net anuncia una plataforma de almacenamiento en la nube que permite a los clientes aprovisionar su propio zpool e importar y exportar datos utilizando zfs send y zfs Receive. ^{[93] [94]}
• 2020: iXsystems comienza el desarrollo de un software hiperconvergente basado en ZFS llamado TrueNAS SCALE, para SOHO y TrueNAS para empresas. ^[91]

En enero de 2010, Oracle Corporation adquirió Sun Microsystems y rápidamente suspendió la distribución OpenSolaris y el modelo de desarrollo de código abierto. ^{[95] [96]} En agosto de 2010, Oracle dejó de proporcionar actualizaciones públicas al código fuente del repositorio Solaris OS/Networking, convirtiendo efectivamente a Solaris 11 nuevamente en un sistema operativo propietario de código cerrado . ^[97]

En respuesta al cambiante panorama de Solaris y OpenSolaris, el proyecto illumos se lanzó a través de un seminario web ^[98] el jueves 3 de agosto de 2010, como un esfuerzo comunitario de algunos ingenieros de Solaris para continuar desarrollando la versión de código abierto de Solaris y completar la apertura de código de aquellas partes que Sun aún no había abierto. ^[99] illumos se fundó como una fundación, la Illumos Foundation, incorporada en el estado de California como una asociación comercial 501(c)6 . El plan original establecía explícitamente que illumos no sería una distribución o una bifurcación. Sin embargo, después de que Oracle anunciara la discontinuación de OpenSolaris, se hicieron planes para bifurcar la versión final de Solaris ON, lo que permitiría a illumos evolucionar hacia un sistema operativo propio. ^[100] Como parte de OpenSolaris, una versión de código abierto de ZFS era, por lo tanto, parte integral de illumos.

ZFS se utilizó ampliamente en numerosas plataformas, además de Solaris. Por lo tanto, en 2013, la coordinación del trabajo de desarrollo de la versión de código abierto de ZFS se transfirió a un proyecto paraguas, OpenZFS . El marco OpenZFS permite que cualquier parte interesada desarrolle de manera colaborativa el código base de ZFS en común, mientras que mantiene de manera individual cualquier código adicional específico que ZFS requiera para funcionar e integrarse dentro de sus propios sistemas.

Nota: La versión de Solaris en desarrollo por Sun desde el lanzamiento de Solaris 10 en 2005 tenía el nombre en código 'Nevada' y se derivaba de lo que era el código base de OpenSolaris . 'Solaris Nevada' es el nombre en código para el sistema operativo Solaris de próxima generación que eventualmente sucedería a Solaris 10 y este nuevo código se incorporó sucesivamente a nuevas compilaciones de instantáneas de OpenSolaris 'Nevada'. ^[101] OpenSolaris ahora está descontinuado y OpenIndiana se bifurcó de él. ^{[102] [103]} Oracle publicó una compilación final (b134) de OpenSolaris (12 de noviembre de 2010) como una ruta de actualización a Solaris 11 Express .

Lista de sistemas operativos, distribuciones y complementos que admiten ZFS, la versión de zpool que admite y la compilación de Solaris en la que se basan (si corresponde):

• Comparación de sistemas de archivos
• Lista de sistemas de archivos
• Sistema de archivos de versiones – Lista de sistemas de archivos de versiones

• ¡Sí, bifurcación! El auge y desarrollo de Illumos: presentación de diapositivas que abarca gran parte de la historia de Solaris, la decisión de Sun de abrir el código fuente, la creación de ZFS y los eventos que provocaron que se cerrara el código fuente y se bifurcara después de la adquisición de Oracle.
• El mejor sistema de archivos en la nube se creó antes de que existiera la nube (archivado el 15 de diciembre de 2018)
• Comparación entre la duplicación de SVM y la duplicación de ZFS
• Distribución de almacenamiento EON ZFS (NAS)
• Integridad de datos de extremo a extremo para sistemas de archivos: un estudio de caso de ZFS
• ZFS – El sistema de archivos Zettabyte (archivado el 28 de febrero de 2013)
• ZFS y RAID-Z: ¿El Über-FS?
• ZFS: La última palabra en sistemas de archivos, por Jeff Bonwick y Bill Moore (archivado el 29 de agosto de 2017)
• Visualización del registro de intenciones de ZFS (ZIL), abril de 2013, por Aaron Toponce
• Características de illumos incluyendo OpenZFS
  • Página wiki anterior con más enlaces: Introducción a ZFS, 15 de septiembre de 2014 (archivado el 30 de diciembre de 2018), parte de la documentación de illumos