Sistema de archivos
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]
Descripción general
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.
Historia
2004-2010: Desarrollo en Sun Microsystems
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]
2010-actualidad: Desarrollo en Oracle, OpenZFS
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.
Características
Resumen
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.
Integridad de los datos
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]
RAID ("RAID-Z")
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 ).
Evitar controladores RAID de hardware
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]
El enfoque de ZFS: RAID-Z y duplicación
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]
Resilvering y scrub (sincronización de matriz y verificación de integridad)
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]
Capacidad
ZFS es un sistema de archivos de 128 bits , [44] [16] por lo que puede manejar 1,84 × 10 19 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 128 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 64 bytes): tamaño máximo de un solo archivo
- 2 48 : número de entradas en cualquier directorio individual [46]
- 16 exbibytes: tamaño máximo de cualquier atributo
- 2 56 : número de atributos de un archivo (en realidad, limitado a 2 48 para la cantidad de archivos en un directorio)
- 256 cuatrillones de zebibytes (2128 bytes ): tamaño máximo de cualquier zpool
- 2 64 : número de dispositivos en cualquier zpool
- 2 64 : número de sistemas de archivos en un zpool
- 2 64 : número de zpools en un sistema
Encriptación
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]
Eficiencia de lectura/escritura
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]
Otras características
Dispositivos de almacenamiento, repuestos y cuotas
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.
Mecanismos de almacenamiento en caché: ARC, L2ARC, grupos de transacciones, ZIL, SLOG, VDEV especial
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.
Clase especial VDEV
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.
Modelo transaccional de copia y escritura
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 ).
Instantáneas y clones
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 .
Enviar y recibir instantáneas
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.
Rayas dinámicas
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]
Tamaños de bloques variables
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]
Creación de sistemas de archivos ligeros
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 ]
Endianidad adaptativa
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.
Desduplicación
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 zpool
y 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.
Capacidades adicionales
- 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.
Limitaciones
- 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.
Recuperación de datos
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.
OpenZFS y ZFS
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]
Productos comerciales y de código abierto
- 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]
Oracle Corporation, código cerrado y bifurcación (a partir de 2010)
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.
Historial de versiones
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 .
Compatibilidad con sistemas operativos
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):
Véase también
Notas
- ^ Si bien RAID 7 no es un nivel RAID estándar, se ha propuesto como un término general para cualquier configuración RAID de paridad >3 [38]
Referencias
- ^ ab "¿Qué es ZFS?". Guía de administración de ZFS de Oracle Solaris . Oracle. Archivado desde el original el 4 de marzo de 2016. Consultado el 29 de diciembre de 2015 .
- ^ "Licencias de ZFS en Linux". GitHub . Consultado el 17 de mayo de 2020 .
- ^ "Se lanza el proyecto OpenZFS". LWN.net . 17 de septiembre de 2013. Archivado desde el original el 4 de octubre de 2013 . Consultado el 1 de octubre de 2013 .
- ^ "Anuncio de OpenZFS". OpenZFS . 17 de septiembre de 2013. Archivado desde el original el 2 de abril de 2018 . Consultado el 19 de septiembre de 2013 .
- ^ open-zfs.org /Historia Archivado el 24 de diciembre de 2013 en Wayback Machine "OpenZFS es el verdadero sucesor de código abierto del proyecto ZFS [...] Efectos de la bifurcación (2010 a la fecha)"
- ^ Sean Michael Kerner (18 de septiembre de 2013). «LinuxCon: OpenZFS hace avanzar el almacenamiento de código abierto». infostor.com. Archivado desde el original el 14 de marzo de 2014. Consultado el 9 de octubre de 2013 .
- ^ "Se lanza el proyecto OpenZFS". LWN.net . 17 de septiembre de 2013. Archivado desde el original el 11 de octubre de 2016 . Consultado el 1 de octubre de 2013 .
- ^ "OpenZFS – Comunidades que cooperan en código y características de ZFS". freebsdnews.net. 23 de septiembre de 2013. Archivado desde el original el 14 de octubre de 2013. Consultado el 14 de marzo de 2014 .
- ^ "Preguntas frecuentes sobre ZFS de Starline". Starline . Consultado el 20 de julio de 2024 .
- ^ ab "19.4. Administración de zfs". www.freebsd.org . Archivado desde el original el 23 de febrero de 2017 . Consultado el 22 de febrero de 2017 .
- ^ Salus, Peter (1994). Un cuarto de siglo de Unix . Addison-Wesley. págs. 199-200. ISBN 0-201-54777-5.
- ^ "¿Qué son SunOS y Solaris?". Base de conocimientos . Servicios de tecnología de la Universidad de Indiana. 20 de mayo de 2013. Consultado el 10 de noviembre de 2014 .
- ^ Brown, David. "Una conversación con Jeff Bonwick y Bill Moore". ACM Queue . Association for Computing Machinery. Archivado desde el original el 16 de julio de 2011. Consultado el 17 de noviembre de 2015 .
- ^ "ZFS: la última palabra en sistemas de archivos". Sun Microsystems. 14 de septiembre de 2004. Archivado desde el original el 28 de abril de 2006. Consultado el 30 de abril de 2006 .
- ^ Matthew Ahrens (1 de noviembre de 2011). «ZFS 10 year anniversary». Archivado desde el original el 28 de junio de 2016. Consultado el 24 de julio de 2012 .
- ^ ab Bonwick, Jeff (31 de octubre de 2005). "ZFS: La última palabra en sistemas de archivos". blogs.oracle.com . Archivado desde el original el 19 de junio de 2013 . Consultado el 22 de junio de 2013 .
- ^ "Sun celebra con éxito el primer aniversario de OpenSolaris". Sun Microsystems. 20 de junio de 2006. Archivado desde el original el 28 de septiembre de 2008. Consultado el 30 de abril de 2018 .
- ^ Michael Singer (25 de enero de 2005). "Sun Cracks Open Solaris". InternetNews.com . Consultado el 12 de abril de 2010 .
- ^ "Preguntas frecuentes sobre ZFS en OpenSolaris.org". Sun Microsystems. Archivado desde el original el 15 de mayo de 2011. Consultado el 18 de mayo de 2011. El
prefijo SI más grande que nos gustó fue "zetta" (no se podía considerar "yotta").
- ^ Jeff Bonwick (3 de mayo de 2006). "Tú dices zeta, yo digo zetta". Blog de Jeff Bonwick . Archivado desde el original el 23 de febrero de 2017. Consultado el 21 de abril de 2017.
Así que finalmente decidimos cambiarle el nombre a ZFS, que no significa nada
. - ^ "Oracle y NetApp desestiman demandas por ZFS". theregister.co.uk. 9 de septiembre de 2010. Archivado desde el original el 9 de septiembre de 2017. Consultado el 24 de diciembre de 2013 .
- ^ El sistema de archivos extendido (Ext) tiene una estructura de metadatos copiada de UFS. «Rémy Card (Entrevista, abril de 1998)». Asociación de abril. 19 de abril de 1999. Archivado desde el original el 4 de febrero de 2012. Consultado el 8 de febrero de 2012 .(En francés)
- ^ Vijayan Prabhakaran (2006). "SISTEMAS DE ARCHIVOS DE HIERRO" (PDF) . Doctor en Filosofía en Ciencias de la Computación . Universidad de Wisconsin-Madison. Archivado (PDF) desde el original el 29 de abril de 2011. Consultado el 9 de junio de 2012 .
- ^ "Paridad perdida y paridad recuperada". Archivado desde el original el 15 de junio de 2010. Consultado el 29 de noviembre de 2010 .
- ^ "Análisis de la corrupción de datos en la pila de almacenamiento" (PDF) . Archivado (PDF) desde el original el 15 de junio de 2010. Consultado el 29 de noviembre de 2010 .
- ^ "Impacto de la corrupción de discos en los DBMS de código abierto" (PDF) . Archivado (PDF) desde el original el 15 de junio de 2010 . Consultado el 29 de noviembre de 2010 .
- ^ Kadav, Asim; Rajimwale, Abhishek. "Análisis de confiabilidad de ZFS" (PDF) . Archivado (PDF) desde el original el 21 de septiembre de 2013. Consultado el 19 de septiembre de 2013 .
- ^ Yupu Zhang; Abhishek Rajimwale; Andrea Arpaci-Dusseau ; Remzi H. Arpaci-Dusseau (2010). "Integridad de datos de extremo a extremo para sistemas de archivos: un estudio de caso de ZFS" (PDF) . Conferencia USENIX sobre tecnologías de archivos y almacenamiento . CiteSeerX 10.1.1.154.3979 . S2CID 5722163. Wikidata Q111972797 . Consultado el 6 de diciembre de 2010 .
- ^ Larabel, Michael. "Evaluación comparativa de ZFS y UFS en FreeBSD frente a EXT4 y Btrfs en Linux". Phoronix Media 2012. Archivado desde el original el 29 de noviembre de 2016. Consultado el 21 de noviembre de 2012 .
- ^ Larabel, Michael. "¿Puede HAMMER de DragonFlyBSD competir con Btrfs y ZFS?". Phoronix Media 2012. Archivado desde el original el 29 de noviembre de 2016. Consultado el 21 de noviembre de 2012 .
- ^ abc Bonwick, Jeff (8 de diciembre de 2005). "ZFS End-to-End Data Integrity". blogs.oracle.com . Archivado desde el original el 3 de abril de 2012. Consultado el 19 de septiembre de 2013 .
- ^ Cook, Tim (16 de noviembre de 2009). "Demonstrating ZFS Self-Healing". blogs.oracle.com . Archivado desde el original el 12 de agosto de 2011 . Consultado el 1 de febrero de 2015 .
- ^ Ranch, Richard (4 de mayo de 2007). «ZFS, copias y protección de datos». blogs.oracle.com . Archivado desde el original el 18 de agosto de 2016. Consultado el 2 de febrero de 2015 .
- ^ ab "zpoolconcepts.7 — Documentación de OpenZFS". openzfs.github.io . Consultado el 5 de abril de 2023 .
- ^ "ZFS sin lágrimas: uso de ZFS sin memoria ECC". www.csparks.com . Diciembre de 2015. Archivado desde el original el 13 de enero de 2021 . Consultado el 16 de junio de 2020 .
- ^ wdc.custhelp.com. «Diferencia entre las unidades de la edición Desktop y la edición RAID (Enterprise)». Archivado desde el original el 5 de enero de 2015. Consultado el 8 de septiembre de 2011 .
- ^ abcd Bonwick, Jeff (17 de noviembre de 2005). "RAID-Z". Blog de Jeff Bonwick . Blogs de Oracle . Archivado desde el original el 16 de diciembre de 2014 . Consultado el 1 de febrero de 2015 .
- ^ ab Leventhal, Adam (17 de diciembre de 2009). "Triple-Parity RAID and Beyond". Cola . 7 (11): 30. doi : 10.1145/1661785.1670144 .
- ^ "Rendimiento, capacidad e integridad de ZFS Raidz". calomel.org . Archivado desde el original el 27 de noviembre de 2017. Consultado el 23 de junio de 2017 .
- ^ "Por qué RAID 6 deja de funcionar en 2019". ZDNet . 22 de febrero de 2010. Archivado desde el original el 31 de octubre de 2014 . Consultado el 26 de octubre de 2014 .
- ^ "No existe una utilidad fsck equivalente para ZFS. Esta utilidad ha servido tradicionalmente para dos propósitos: la reparación y la validación del sistema de archivos". "Comprobación de la integridad del sistema de archivos de ZFS". Oracle. Archivado desde el original el 31 de enero de 2013. Consultado el 25 de noviembre de 2012 .
- ^ "ZFS Scrubs". freenas.org. Archivado desde el original el 27 de noviembre de 2012. Consultado el 25 de noviembre de 2012 .
- ^ "También debe ejecutar una limpieza antes de reemplazar dispositivos o reducir temporalmente la redundancia de un grupo para asegurarse de que todos los dispositivos estén operativos actualmente". "Guía de mejores prácticas de ZFS". solarisinternals.com. Archivado desde el original el 5 de septiembre de 2015. Consultado el 25 de noviembre de 2012 .
- ^ Jeff Bonwick. "Almacenamiento de 128 bits: ¿estás en lo cierto?". oracle.com . Archivado desde el original el 29 de mayo de 2015. Consultado el 29 de mayo de 2015 .
- ^ "ZFS: Hierve el océano, consume la luna (Blog de Dave Brillhart)". Archivado desde el original el 8 de diciembre de 2015 . Consultado el 19 de diciembre de 2015 .
- ^ "Guía de administración de Solaris ZFS". Oracle Corporation. Archivado desde el original el 13 de enero de 2021. Consultado el 11 de febrero de 2011 .
- ^ "Cifrado de sistemas de archivos ZFS". Archivado desde el original el 23 de junio de 2011 . Consultado el 2 de mayo de 2011 .
- ^ "Tener mi pastel seguro y clonarlo también (también conocido como cifrado + deduplicación con ZFS)". Archivado desde el original el 29 de mayo de 2013 . Consultado el 9 de octubre de 2012 .
- ^ «ZFS – Wiki de Debian». wiki.debian.org . Archivado desde el original el 8 de septiembre de 2019. Consultado el 10 de diciembre de 2019 .
- ^ "Propuesta: considerar agregar advertencias contra el uso del cifrado nativo de zfs junto con send/recv en producción". Github . Github . Consultado el 15 de agosto de 2024 .
- ^ "PSA: ZFS tiene un error de corrupción de datos cuando se utiliza cifrado nativo y envío/recepción". Reddit . Reddit . Consultado el 15 de agosto de 2024 .
- ^ "Fragmentación de ZFS: soluciones a largo plazo". Github . Github . Consultado el 15 de agosto de 2024 .
- ^ "¿Cuáles son las mejores prácticas para evitar que ZFS se fragmente demasiado?". Lawrence Systems . Lawrence Systems . Consultado el 15 de agosto de 2024 .
- ^ "Solaris ZFS permite grupos de almacenamiento híbridos: rompe barreras económicas y de rendimiento" (PDF) . Sun.com. 7 de septiembre de 2010. Archivado (PDF) desde el original el 17 de octubre de 2011 . Consultado el 4 de noviembre de 2011 .
- ^ Gregg, Brendan. "ZFS L2ARC". Blog de Brendan . Dtrace.org. Archivado desde el original el 6 de noviembre de 2011. Consultado el 5 de octubre de 2012 .
- ^ Gregg, Brendan (8 de octubre de 2009). «Hybrid Storage Pool: Top Speeds» (Grupo de almacenamiento híbrido: máximas velocidades). Blog de Brendan . Dtrace.org. Archivado desde el original el 5 de abril de 2016. Consultado el 15 de agosto de 2017 .
- ^ "Ajuste del rendimiento de Solaris ZFS: escrituras sincrónicas y ZIL". Constantin.glez.de. 20 de julio de 2010. Archivado desde el original el 23 de junio de 2012. Consultado el 5 de octubre de 2012 .
- ^ abc "Release zfs-0.8.0". GitHub . OpenZFS. 23 de mayo de 2019 . Consultado el 3 de julio de 2021 .
- ^ "Especificación de ZFS On-Disk" (PDF) . Sun Microsystems, Inc. 2006. Archivado desde el original (PDF) el 30 de diciembre de 2008.Véase la sección 2.4.
- ^ "RAIDZ — Documentación de OpenZFS". openzfs.github.io . Consultado el 9 de febrero de 2023 .
- ^ Eric Sproul (21 de mayo de 2009). «ZFS Nuts and Bolts». slideshare.net. pp. 30–31. Archivado desde el original el 22 de junio de 2014. Consultado el 8 de junio de 2014 .
- ^ "ZFS Deduplication". blogs.oracle.com . Archivado desde el original el 24 de diciembre de 2019 . Consultado el 25 de noviembre de 2019 .
- ^ Gary Sims (4 de enero de 2012). "Building ZFS Based Network Attached Storage Using FreeNAS 8" (Construcción de un sistema de almacenamiento conectado a la red basado en ZFS mediante FreeNAS 8). Capacitación de TrainSignal . TrainSignal, Inc. Archivado desde el original (Blog) el 7 de mayo de 2012. Consultado el 9 de junio de 2012 .
- ^ Ray Van Dolson (mayo de 2011). «[zfs-discuss] Resumen: Requisitos de memoria para deduplicación». Lista de correo zfs-discuss. Archivado desde el original el 25 de abril de 2012.
- ^ "ZFSTuningGuide". Archivado desde el original el 16 de enero de 2012 . Consultado el 3 de enero de 2012 .
- ^ Chris Mellor (12 de octubre de 2012). «GreenBytes presenta un clon completo de bomba VDI». The Register . Archivado desde el original el 24 de marzo de 2013. Consultado el 29 de agosto de 2013 .
- ^ Chris Mellor (1 de junio de 2012). «Newcomer saca su caja y planea venderla a bajo precio a todos los interesados». The Register . Archivado desde el original el 12 de agosto de 2013. Consultado el 29 de agosto de 2013 .
- ^ Chris Mellor (11 de diciembre de 2014). «Dedupe, dedupe... dedupe, dedupe, dedupe: Oracle pule el diamante de ZFS». The Register . Archivado desde el original el 7 de julio de 2017. Consultado el 17 de diciembre de 2014 .
- ^ "Sumas de comprobación y su uso en ZFS". github.com . 2 de septiembre de 2018. Archivado desde el original el 19 de julio de 2019 . Consultado el 11 de julio de 2019 .
- ^ "Guía de administración de Solaris ZFS". Capítulo 6 Administración de sistemas de archivos ZFS . Archivado desde el original el 5 de febrero de 2011. Consultado el 17 de marzo de 2009 .
- ^ "Smokin' Mirrors". blogs.oracle.com . 2 de mayo de 2006. Archivado desde el original el 16 de diciembre de 2011 . Consultado el 13 de febrero de 2012 .
- ^ "ZFS Block Allocation". Blog de Jeff Bonwick . 4 de noviembre de 2006. Archivado desde el original el 2 de noviembre de 2012. Consultado el 23 de febrero de 2007 .
- ^ "Ditto Blocks — El asombroso repelente de cinta". Blog Flippin' off bits . 12 de mayo de 2006. Archivado desde el original el 26 de mayo de 2013. Consultado el 1 de marzo de 2007 .
- ^ "Añadir nuevos discos y comportamiento de bloque idéntico". Archivado desde el original el 23 de agosto de 2011 . Consultado el 19 de octubre de 2009 .
- ^ "OpenSolaris.org". Sun Microsystems. Archivado desde el original el 8 de mayo de 2009. Consultado el 22 de mayo de 2009 .
- ^ "Novedades de Solaris 11 Express 2010.11" (PDF) . Oracle. Archivado (PDF) del original el 16 de noviembre de 2010 . Consultado el 17 de noviembre de 2010 .
- ^ "10. Compartir — Guía del usuario de FreeNAS 9.3 Tabla de contenidos". doc.freenas.org . Archivado desde el original el 7 de enero de 2017 . Consultado el 23 de febrero de 2017 .
- ^ "Bug ID 4852783: reduce pool capacity" (ID de error 4852783: reducir la capacidad del pool). Proyecto OpenSolaris. Archivado desde el original el 29 de junio de 2009. Consultado el 28 de marzo de 2009 .
- ^ Goebbels, Mario (19 de abril de 2007). "Eliminación permanente de desarrolladores virtuales de un pool". zfs-discuss (Lista de correo).[ enlace muerto permanente ] enlace de archivo Archivado el 13 de enero de 2021 en Wayback Machine
- ^ Chris Siebenmann Información sobre la futura eliminación de vdev Archivado el 11 de agosto de 2016 en Wayback Machine , Univ Toronto, blog, cita: anuncio informal en Twitter de Alex Reece Archivado el 11 de agosto de 2016 en Wayback Machine
- ^ "Funciones de gestión de datos: novedades de Oracle® Solaris 11.4". Archivado desde el original el 24 de septiembre de 2019 . Consultado el 9 de octubre de 2019 .
- ^ "Expand-O-Matic RAID Z". Adam Leventhal. 7 de abril de 2008. Archivado desde el original el 28 de diciembre de 2011. Consultado el 16 de abril de 2012 .
- ^ "Juguete ZFS". SourceForge.net . Consultado el 12 de abril de 2022 .
- ^ "zpoolconcepts(7)". Documentación de OpenZFS . OpenZFS. 2 de junio de 2021 . Consultado el 12 de abril de 2021 .
Los dispositivos virtuales no se pueden anidar, por lo que un espejo o un dispositivo virtual raidz solo puede contener archivos o discos. No se permiten espejos de espejos (u otras combinaciones).
- ^ "zpool(1M)". Download.oracle.com. 11 de junio de 2010. Archivado desde el original el 13 de enero de 2021 . Consultado el 4 de noviembre de 2011 .
- ^ "Turbocargando la recuperación de datos de ZFS". Archivado desde el original el 29 de noviembre de 2018 . Consultado el 29 de noviembre de 2018 .
- ^ "ZFS y OpenZFS". iXSystems . Consultado el 18 de mayo de 2020 .
- ^ "Sun presenta sus propios dispositivos de almacenamiento". techworld.com.au. 11 de noviembre de 2008. Archivado desde el original el 13 de noviembre de 2013. Consultado el 13 de noviembre de 2013 .
- ^ Chris Mellor (2 de octubre de 2013). "Oracle se abre paso hasta ocupar un puesto en la cima de la clasificación con un potente archivador ZFS". theregister.co.uk. Archivado desde el original el 7 de julio de 2017. Consultado el 7 de julio de 2014 .
- ^ "Dispositivo de almacenamiento ZFS unificado creado en Silicon Valley por iXsystem". ixsystems.com. Archivado desde el original el 3 de julio de 2014. Consultado el 7 de julio de 2014 .
- ^ ab "¡TrueNAS 12 y TrueNAS SCALE ya están aquí oficialmente!". ixsystems.com . Consultado el 2 de enero de 2021 .
- ^ "ReadyDATA 516 – Almacenamiento en red unificado" (PDF) . netgear.com. Archivado (PDF) del original el 15 de julio de 2014 . Consultado el 7 de julio de 2014 .
- ^ Jim Salter (17 de diciembre de 2015). «rsync.net: la replicación de ZFS en la nube finalmente está aquí y es rápida». arstechnica.com. Archivado desde el original el 22 de agosto de 2017. Consultado el 21 de agosto de 2017 .
- ^ rsync.net, Inc. «Almacenamiento en la nube con envío y recepción ZFS a través de SSH». rsync.net. Archivado desde el original el 21 de julio de 2017. Consultado el 21 de agosto de 2017 .
- ^ Steven Stallion / Oracle (13 de agosto de 2010). «Actualización sobre SXCE». Tendencias iconoclastas. Archivado desde el original el 9 de noviembre de 2020. Consultado el 30 de abril de 2018 .
- ^ Alasdair Lumsden. «OpenSolaris cancelado, será reemplazado por Solaris 11 Express». osol-discuss (Lista de correo). Archivado desde el original el 16 de agosto de 2010. Consultado el 24 de noviembre de 2014 .
- ^ Solaris todavía está abierto, pero la distribución OpenSolaris está muerta Archivado el 5 de septiembre de 2017 en Wayback Machine en Ars Technica por Ryan Paul (16 de agosto de 2010)
- ^ Garrett D'Amore (3 de agosto de 2010). "Illumos - La esperanza y la luz vuelven a brotar - Presentado por Garrett D'Amore" (PDF) . illumos.org . Consultado el 3 de agosto de 2010 .
- ^ "¿Hacia dónde va OpenSolaris? Illumos asume el mando". Archivado desde el original el 26 de septiembre de 2015.
- ^ Garrett D'Amore (13 de agosto de 2010). "La mano puede ser forzada" . Consultado el 14 de noviembre de 2013 .
- ^ abc "Mientras estaba bajo el control de Sun Microsystems, se publicaban instantáneas quincenales de Solaris Nevada (el nombre en código del sistema operativo Solaris de próxima generación que eventualmente sucedería a Solaris 10) y este nuevo código se incorporaba a nuevas instantáneas de vista previa de OpenSolaris disponibles en Genunix.org. Las versiones estables de OpenSolaris se basan en [ sic ] estas compilaciones de Nevada". Larabel, Michael. "Parece que Oracle respaldará a OpenSolaris". Phoronix Media. Archivado desde el original el 29 de noviembre de 2016. Consultado el 21 de noviembre de 2012 .
- ^ Ljubuncic, Igor (23 de mayo de 2011). «OpenIndiana: todavía hay esperanza». DistroWatch . Archivado desde el original el 27 de octubre de 2012. Consultado el 21 de noviembre de 2012 .
- ^ "¡Bienvenidos al Proyecto OpenIndiana!". Proyecto OpenIndiana. 10 de septiembre de 2010. Archivado desde el original el 27 de noviembre de 2012. Consultado el 14 de septiembre de 2010 .
- ^ "Versiones de pool ZFS". Oracle Corporation. 2022. Archivado desde el original el 21 de diciembre de 2022. Consultado el 1 de enero de 2023 .
Bibliografía
- Watanabe, Scott (23 de noviembre de 2009). Solaris ZFS Essentials (1.ª ed.). Prentice Hall . pág. 256. ISBN. 978-0-13-700010-4. Archivado desde el original el 1 de octubre de 2012.
Enlaces externos
- ¡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