ZFS

Este artículo está sobre el sistema de archivos de Sun Microsystems. Para otras aplicaciones, vea ZFS (desambiguación).

ZFS

Desarrolladores	Oracle Corporation
Nombre completo	ZFS
Introducido	Noviembre de 2005 con OpenSolaris
Estructuras
Contenido de directorios	Tabla hash extensible
Límites
Max. tamaño del volumen	256000 trilloneszebibytes (2128bytes)
Max. tamaño del archivo	16exbibytes (264bytes)
Max. número de archivos	Por directorio: 248 Por sistema de archivos: ilimitado
Max. longitud de nombre de archivo	255 ASCII caracteres (menos para multibyte codificaciones del carácter tales como Unicode)
Características
Horquillas	Sí (llamado "atributos extendidos", pero son corrientes de pleno derechos)
Atributos	POSIX
Permisos del sistema de archivo	POSIX, ACL de NFSv4
Compresión transparente	Sí
Cifrado transparente	Sí
Desduplicación de datos	Sí
Copy-on-write	Sí
Otros
Apoyado sistemas operativos	Solaris, OpenSolaris, IllumOS distribuciones, OpenIndiana, FreeBSD, Mac OS X Server 10.5 (sólo soporte de sólo lectura), NetBSD, Linux través de terceros módulo del núcleo o ZFS-FUSIBLE, OSv)

ZFS es una combinación sistema de archivos y Administrador de volúmenes lógicos diseñado por Sun Microsystems. Las características de ZFS incluyen protección contra corrupción de datos, soporte para capacidades de almacenamiento alta, compresión de datos eficientes, integración de los conceptos de sistema de archivos y Administración de volúmenes, instantáneas y Copy-on-write clones, reparación automática y continua integridad RAID-Z y nativas NFSv4 ACL.

El nombre ZFS está registrado como una marca registrada de Oracle Corporation; Aunque fue brevemente dado el adaptado nombre expandido "Zettabyte File System", ya no se considera un initialism. Originalmente, fue propietaria, ZFS software de código cerrado desarrollado internamente por el sol como parte de Solaris, con un equipo dirigido por el director de unidad de negocio de almacenamiento de información de sol y sol compañero, Jeff Bonwick. En 2005, la mayor parte de Solaris, como ZFS, obtuvo la licencia como software de código abierto bajo la Desarrollo común y licencia de distribución (CDDL), como la OpenSolaris proyecto. ZFS se convirtió en una característica estándar de Solaris 10 en junio de 2006.

En 2010, Oracle detiene la liberación del código fuente para un nuevo desarrollo de OpenSolaris y ZFS, efectivamente que se bifurcan su desarrollo de código cerrado de la abrir-fuente rama. En respuesta, OpenZFS fue creado como un nuevo proyecto de desarrollo de código abierto paraguas, con el objetivo de reunir a personas y empresas que utilizan el sistema de archivos ZFS de forma libre.

Resumen y objetivos de diseño de sistemas

En comparación con más otros sistemas de archivos ZFS

Históricamente, la gestión de los datos almacenados ha involucrado dos aspectos: la gestión física de los dispositivos de bloque tales como unidades de disco duros y Tarjetas SDy los dispositivos tales como Controladores RAID que presentan un único dispositivo lógico basado en múltiples dispositivos físicos (a menudo realizadas por un Administrador de volúmenes, Gerente de matriz, o dispositivo adecuado controlador) y la gestión de archivos como unidades lógicas en estos dispositivos de bloque lógico (un sistema de archivos).

Ejemplo: A Conjunto RAID de 2 unidades de disco duros y un disco SSD disco caché es controlada por Sistema RST de Intel, parte de la chipset y firmware construido en una computadora de escritorio. El usuario ve esto como un solo volumen, que contiene una unidad con formato NTFS de sus datos, y no es necesariamente consciente de las manipulaciones que pueden necesitar (como NTFS reconstrucción de la matriz RAID Si un disco falla). La gestión de los dispositivos individuales y su presentación como un único dispositivo, es distinta de la gestión de los archivos en dispositivo aparente.

ZFS es inusual, porque a diferencia de la mayoría de los otros sistemas de almacenamiento, unifica ambos de estos roles y actúa como el administrador de volúmenes y el sistema de archivos. Por lo tanto, tiene un conocimiento completo de los discos físicos y volúmenes (incluyendo su condición, estado, la disposición lógica en volúmenes y también de todos los archivos almacenados en ellos). ZFS está diseñado para asegurar (con adecuado hardware) que los datos almacenados en discos no pueden ser perdidos debido a errores físicos o misprocessing por el hardware o Sistema operativo, o putrefacción de la broca eventos y corrupción de datos que puede suceder con el tiempo, y su control completo del sistema de almacenamiento se utiliza para asegurar cada paso, ya sea relacionados con la gestión de archivos or Administración de discos, es verificado, confirmado, corregida si es necesario y optimizada, de forma que tarjetas de controlador de almacenamiento, y gerentes de volumen y archivo separados no pueden lograr.

ZFS también incluye un mecanismo para instantáneas y replicación, incluyendo snapshot clonación; el primero es descrito por la FreeBSD documentación como uno de sus "características más de gran alcance", características que "incluso otros sistemas de archivos con falta de funcionalidad de copias instantáneas". Puede tomarse una gran cantidad de fotos, sin degradar el rendimiento, permitiendo copias instantáneas a utilizarse antes de la operación del sistema de riesgo y cambios de software o un sistema de archivos (en "vivo") de toda la producción para ser snapshotted varias veces una hora, con el fin de mitigar la pérdida de datos debido a error de usuario o doloso. Las instantáneas pueden se deshacen "en vivo" o el sistema de archivos en los puntos anteriores en el tiempo visto, incluso en sistemas de archivo muy grande, llevando a ahorros "tremendos" en comparación con el respaldo formal y los procesos de restauración, o reproducido "in situ" para sistemas de archivo independiente nueva forma.

Resumen de clave diferenciar características

Ejemplos de funciones específicas a ZFS que facilitan su objetivo incluyen:

• Diseñado para almacenamiento de datos de largo plazo, y escalan indefinidamente tamaños de almacén de datos con cero pérdida de datos y la alta capacidad de configuración.
• Jerárquica sumas de comprobación de de todos los datos y metadatos de, asegurando que el sistema de almacenamiento de información puede ser verificado el uso y confirmado para ser almacenados correctamente, o remediado si corruptos. Sumas de comprobación se almacenan con los padres de un bloque bloque, en lugar de con el propio bloque. Esto contrasta con muchos sistemas de archivos donde se almacenan los sumas de comprobación (si) con los datos de modo que si los datos están perdidos o corruptos, la suma de comprobación también es probable que sea perdido o incorrecto.
• Puede almacenar un número especificado por el usuario de copias de datos o metadatos, o seleccionados los tipos de datos, para mejorar la capacidad para recuperarse de daños en los datos de los archivos importantes y estructuras.
• Restauración automática de los cambios recientes al sistema de archivos y datos, en algunas circunstancias, en caso de error o inconsistencia.
• Automatizados y (generalmente) silenciosa resolución automática de problemas de inconsistencias de datos y la falta de escritura cuando se detecta, para todos los errores en los datos están capaces de reconstrucción. Datos se pueden reconstruir utilizando lo siguiente: error detección y corrección de sumas de comprobación en cada bloque de los padres; múltiples copias de datos (incluyendo sumas de comprobación) en el disco; escribir intenciones ha iniciado sesión en el SLOG (ZIL) escrituras que debe haber ocurrido pero que no ocurrió (después de un apagón); datos de la paridad de los discos RAID/RAIDZ y volúmenes; copias de datos de discos espejados y volúmenes.
• Nativa de manejo de niveles RAID estándar y diseños de sistemas RAID adicionales ("RAIDZ"). Los niveles RAIDZ raya datos en sólo los discos necesarios, para la eficacia (muchos RAID sistemas la raya indiscriminadamente en todos los dispositivos), y sumas de comprobación permite reconstrucción de datos incompatibles o corruptos para reducirse a esos bloques con defectos;
• Nativa de manejo de almacenamiento y dispositivos de almacenamiento en caché, que suele ser una tarea relacionados con volumen. Porque también comprende el sistema de archivos, puede utilizar los conocimientos relacionados con el archivo para informar, integrar y optimizar su almacenamiento, manipulación que no puede un dispositivo separado;
• Manejo nativo de copias instantáneas y backup /replicación que pueden hacerse eficientes integrando el volumen y manejo de archivos. ZFS puede rutinariamente tomar instantáneas varias veces una hora del sistema de datos eficaz y rápida. Herramientas se encuentran en un nivel bajo y requieren scripts externos y software de utilización.
• Nativo compresión de datos y deduplicación, aunque este último se maneja en gran parte en MEMORIA RAM y tiene memoria de hambre.
• Reconstrucción eficaz de arreglos RAID, un controlador RAID a menudo tiene que reconstruir un disco entero, pero ZFS puede combinar conocimientos de disco y archivo para limitar cualquier reconstrucción de datos que realmente falta o corruptos, mucho acelerar reconstrucción;
• Capacidad para identificar los datos que habría encontrados en una memoria caché, pero ha sido descartados recientemente; Esto permite que ZFS a reevaluar sus decisiones a la luz de uso posterior y facilita la caché muy alto golpe niveles;
• Estrategias alternativas de almacenamiento en caché se pueden utilizar para los datos que de lo contrario causaría retrasos en el manejo de datos. Por ejemplo, síncrono escribe que es capaces de ralentizar el sistema de almacenamiento se puede convertir a escrituras asincrónicas por se escriben en un dispositivo de almacenamiento en caché rápido separado, conocido como el SLOG (a veces llamado ZIL - registro de intentos de ZFS).
• Altamente configurable - muchos parámetros internos pueden configurarse para funcionamiento óptimo.
• Puede ser utilizado para alta disponibilidad racimos y computación, aunque no completamente diseñada para este uso.

Sistemas inadecuadamente especificados

A diferencia de muchos sistemas de archivos, ZFS se pretende trabajar de forma específica y con fines específicos. Se espera que o está diseñada con la asunción de un tipo específico de entorno de hardware. Si el sistema no es adecuado para ZFS, entonces puede hacerlas ZFS significativamente. Fallas comunes del diseño de sistema:

• Memoria RAM insuficiente ZFS puede utilizar una gran cantidad de memoria en muchos escenarios;
• Espacio libre en disco insuficiente — ZFS utiliza una copia de la escritura almacenamiento de datos; su funcionamiento puede sufrir si la piscina de disco se hace demasiado completo;
• 'No eficiente dispositivo SLOG dedicado, cuando Escritura sincrónica es prominente — Éste es especialmente el caso para NFS y ESXi; incluso los sistemas SSD basado pueden necesitar un dispositivo separado del SLOG de rendimiento esperado. El dispositivo SLOG es utilizado para la escritura aparte de al recuperarse de un error del sistema. A menudo pueden ser pequeña (por ejemplo, en FreeNASel dispositivo SLOG sólo necesita almacenar la mayor cantidad de datos probablemente escrita en unos 10 segundos (o el tamaño de dos grupos de' transacciones'), aunque puede ser hecho más grande para permitir que más larga vida del dispositivo). SLOG por lo tanto es inusual en que sus criterios principales son escribir pura funcionalidad, baja latencia y pérdida de protección - generalmente poco importa.
• Falta de caché adecuado o cachés misdesigned — por ejemplo, ZFS puede almacenar en caché datos leídos de memoria RAM ("arco") o un dispositivo independiente "(L2ARC del); en algunos casos añadir arco extra es necesaria, en otros casos agregar L2ARC extra es necesaria, y en algunas situaciones añadiendo L2ARC extra puede incluso disminuir el rendimiento, obligando a la RAM para datos de búsqueda para la L2ARC más lento, a costa de menos espacio para datos en el arco.
• 'Uso de la tarjetas RAID de hardware, quizás en la creencia errónea de que estos 'ayudará a' ZFS. Rutina para otros sistemas de presentación, ZFS maneja nativamente, RAID y está diseñado para trabajar con una materia prima y sin modificar bajo nivel vista de dispositivos de almacenamiento, por lo que puede utilizar completamente su funcionalidad. Una tarjeta RAID puede dejar ZFS menos eficiente y confiable. Por ejemplo de ZFS sumas para que todos los datos, pero la mayoría de tarjetas RAID no hará esto con eficacia, o cachean de datos. Tarjetas separadas también pueden engañar ZFS sobre el estado de los datos, por ejemplo después de un accidente, o por mal señalización exactamente cuando datos de forma segura se ha escrito, y en algunos casos esto puede conducir a problemas y pérdida de datos. Tarjetas separadas pueden también ralentizar el sistema, a veces considerablemente, añadiendo latencia de para cada operación de lectura/escritura de datos, o por completo de la empresa reconstrucciones de matrices dañadas donde ZFS sólo habría necesitado a menores reparaciones de unos pocos segundos.

Características

Integridad de los datos

Vea también: Manejo y tasas de error de disco duro y Corrupción de datos silenciosa

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 mediante la protección de los datos del usuario en disco contra corrupción de datos silenciosa causada por degradación de datos, actual espigas, errores en disco firmware, escribe Fantasma (la escritura anterior no hizo en el disco), dirección (el disco tiene acceso a la cuadra mal) lee y escribe, sobrescribe los errores de paridad DMA entre la matriz y el servidor de la memoria o del conductor (ya que la suma de comprobación valida datos dentro de la matriz), errores de controlador (datos vientos para arriba en el búfer incorrecto dentro del núcleo), accidental (como cambiar a un sistema vivo archivo) , etcetera.

Una investigación de 2012 mostraron que ni ninguno de los entonces importantes y generalizado sistemas de archivos (tales como UFS, Ext, XFS, JFS, o NTFS) ni hardware RAID (que tiene algunos problemas con la integridad de los datos) proporcionan suficiente protección contra problemas de corrupción de datos. La investigación inicial indica que ZFS protege los datos mejores que anteriores esfuerzos. También es más rápido que UFS y puede ser visto como su reemplazo.

Integridad de datos ZFS

Para ZFS, integridad de los datos se logra mediante el uso de un Base de Fletcher suma de comprobación o un SHA-256 hash a través del árbol de sistema de archivo. Cada bloque de datos es checksum y el valor de suma de comprobación se guarda entonces en el puntero para que el bloque, en lugar de interrumpir en el real sí mismo. A continuación, el puntero de bloque es checksum, el valor se guarda en su puntero. Esta sumas de comprobación continúa todo el camino hasta la jerarquía del sistema de archivos de datos al nodo raíz, que es también checksum, creando así un Merkle tree. Corrupción de datos durante el vuelo o fantasma Lee y escribe (los datos escrito lectura y sumas de comprobación correctamente pero está realmente mal) son indetectable por los sistemas de ficheros más la suma de comprobación con los datos de la tienda. ZFS almacena la suma de comprobación de cada bloque en su puntero de bloque de padre para que toda la piscina uno mismo-valida.

Cuando se accede a un bloque, independientemente de si es datos o metadatos, su suma de comprobación se calcula y compara con el valor de suma de comprobación almacenada de lo que "debería" ser. Si las sumas coinciden, los datos se pasan encima de la pila de programación para el proceso que pidió para él; Si los valores no coinciden, entonces ZFS puede curar los datos si la piscina de almacenamiento de información proporciona redundancia de datos (como con internos espejado), asumiendo que la copia de datos no esté dañada y con emparejar sumas de comprobación. Si la agrupación de almacenamiento consta de un solo disco, es posible proporcionar tal redundancia especificando copias = 2 (o copias = 3), que significa que los datos se almacenarán dos veces (o tres veces) en el disco, efectivamente reducir a la mitad (o, para copias = 3reduciendo a un tercio) la capacidad de almacenamiento del disco. Si existe redundancia, ZFS se buscar una copia de los datos (o crearla mediante un mecanismo de recuperación RAID) y recalcular el checksum, idealmente dando por resultado la reproducción del valor originalmente esperado. Si los datos pasa esta verificación de la integridad, el sistema puede entonces actualizar la copia defectuosa con datos de buen que redundancia puede ser restaurada.

RAID

Sistemas y hardware RAID

Si los discos están conectados a una controladora RAID, es más eficiente para configurarlo como un HBA en JBOD modo (es decir, apague la función RAID). Si se utiliza una tarjeta RAID de hardware, ZFS siempre detecta los daños en los datos pero siempre no puede reparar daños en los datos porque interfiere en la tarjeta RAID de hardware. Por lo tanto, la recomendación es no usar una tarjeta RAID de hardware, o a una tarjeta RAID de hardware flash en JBOD / modo de ti. Para ZFS poder garantizar la integridad de los datos necesita o tiene acceso a un conjunto RAID (así que todos los datos se copia en al menos dos discos), o si se utiliza un único disco, ZFS necesita habilitar redundancia (copias) que duplica los datos en la misma unidad lógica. Uso de ZFS copias es una buena característica para usar en notebooks y computadoras de escritorio, ya que los discos son grandes y por lo menos proporciona una cierta redundancia limitada a una sola unidad.

Hay varias razones por qué es mejor que depender únicamente de ZFS mediante el uso de varios discos independientes y RAID-Z o espejado.

Al utilizar hardware RAID, el controlador agrega generalmente dependiente del controlador de datos a las unidades que impide el acceso a los datos del usuario RAID por software. Mientras que es posible leer los datos con un controlador RAID de hardware compatible, esto inconvenientes a los consumidores como un controlador compatible generalmente no está fácilmente disponible. Mediante la combinación de JBOD/RAID-Z, cualquier controlador de disco puede utilizarse para reanudar el funcionamiento después de un fallo en el controlador.

Nota que el hardware RAID configurado como JBOD puede todavía separar unidades que no responden a tiempo (como se ha visto con muchos discos duros de calidad para consumidores eficientes) y como tal, pueden requerir TLER/ CCTL/ERC habilitados unidades para evitar a abandonos en coche.

Software RAID uso de ZFS

Vea también: § De niveles RAID estándar RAID Z

ZFS ofrece RAID por software a través de su RAID-Z y espejado de esquemas de organización.

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 raya RAID, independientemente del tamaño de bloque, dando por resultado cada escritura RAID-Z siendo una escritura completa-raya. Esto, combinado con la semántica transaccional copy-on-write ZFS, elimina la escribir error de agujero. RAID-Z es también más rápido que el tradicional RAID 5 ya que no es necesario llevar a cabo la habitual leer-modificar-escribir secuencia.

Como todas las tendencias son de diferentes tamaños, reconstrucción de RAID-Z tiene que atravesar los metadatos del sistema de archivos para determinar la geometría real de RAID-Z. Esto sería imposible si el sistema de archivos y la matriz RAID productos separados, mientras que se vuelve factible cuando hay una visión integrada de la estructura lógica y física de los datos. Ir a través de los metadatos significa que ZFS puede validar cada bloque contra su 256 bits de comprobación como se va, mientras que los productos RAID tradicionales generalmente no pueden hacer esto.

Además de manejar fallas de conjunto disco, RAID-Z puede también detectar y corregir corrupción de datos silenciosa, que ofrece "datos de auto-sanación": al leer un bloque de RAID-Z, ZFS compara contra su comprobación, y si los discos de datos no devolvió la respuesta correcta, ZFS lee la paridad y luego las figuras a que disco devuelve datos incorrectos. Luego, repara los datos dañados y devuelve buenos datos al solicitante.

RAID-Z no requiere ningún hardware especial: no es necesario NVRAM para la confiabilidad, y no es necesario escribir el almacenamiento en búfer para el buen funcionamiento. Con RAID-Z, ZFS proporciona rápido, confiable almacenamiento barato, usando discos de materia.

Hay tres diferentes modos de RAID-Z: RAID-Z1 (similar al RAID 5, permite que un disco falle), RAID-Z2 (similar a RAID 6, permite comparar dos discos a fallar), y RAID-Z3 (permite tres discos al fracaso). La necesidad de RAID-Z3 surgió recientemente porque las configuraciones de RAID con discos de futuro (digamos, 6 – 10 TB) pueden tomar mucho tiempo para reparar, el peor de los casos siendo semanas. Durante esas semanas, el resto de los discos de la banda se destacó más por el proceso de reparación intensiva adicional y puede fallar posteriormente, demasiado. Mediante el uso de RAID-Z3, se reduce el riesgo involucrado con el reemplazo de disco.

Espejo, la otra opción de RAID de ZFS, es esencialmente lo mismo que RAID 1, lo que permite cualquier número de discos se espejen.

Actualizar la duplicación y matorral

ZFS no tiene ninguna herramienta equivalente a fsck (el estándar Unix y Linux datos control y reparación herramienta para sistemas de archivos). En cambio, ZFS posee un Scrub función que regularmente examina todos los datos de reparaciones y corrupción silenciosa y otros problemas. Algunas diferencias son:

• debe ejecutar fsck en un sistema de ficheros fuera de línea, que significa el sistema de archivos debe ser desmontado y no es utilizable mientras se repara, si bien está diseñado para ser utilizado en un sistema de archivos montado, vivo y no es necesario el sistema de archivos ZFS para ser tomado fuera de línea.
• fsck normalmente sólo analiza los metadatos (como el registro de diario) pero nunca comprueba los datos sí mismo. Esto significa que después de un fsck, los datos pueden ser corruptos.
• fsck no puede validar siempre y reparación de datos cuando sumas de comprobación se almacenan con los datos (a menudo el caso en muchos sistemas de archivos), porque las sumas de control también pueden ser dañado o ilegible. ZFS almacena siempre sumas de comprobación por separado de los datos que verificar, mejorar la fiabilidad y la capacidad de fregar para reparar el volumen. ZFS también almacena múltiples copias de datos, metadatos en particular pueden tener más de 4 o 6 ejemplares (múltiples copias por disco) y los múltiples espejos de disco por volumen, grandemente mejorando la capacidad del scrub para detectar y reparar daños al volumen, en comparación con fsck.
• matorral comprueba todo, incluyendo los datos y metadatos. El efecto puede observarse comparando fsck para fregar veces – a veces un fsck en una incursión grande completa en pocos minutos, lo que significa que sólo los metadatos se comprueban. Recorrer todos los datos y metadatos en una incursión grande toma muchas horas, que es exactamente lo que friega.

La recomendación oficial de Sun/Oracle es fregar discos de nivel empresarial una vez al mes y los discos de materia más baratos una vez por semana.

Capacidad

ZFS es un 128-bit sistema de archivos, así que puede direccionar 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 grande que nunca debe ser encontrados en la práctica. Por ejemplo, rellenar completamente un zpool solo con 2¹²⁸ bits de datos requeriría 10²⁴ unidades de disco duro de 3 TB.

Algunos límites teóricos en ZFS son:

• 2⁴⁸: número de entradas en un directorio individual
• 16 exbibytes (2⁶⁴ bytes): tamaño máximo de un archivo
• 16 exbibytes: tamaño máximo de cualquier atributo
• 256000 trillones zebibytes (2¹²⁸ bytes): tamaño máximo de cualquier zpool
• 2⁵⁶: número de atributos de un archivo (realmente limitado a 2⁴⁸ para el número de archivos en un directorio)
• 2⁶⁴: número de dispositivos en cualquier zpool
• 2⁶⁴: número de zpools en un sistema de
• 2⁶⁴: número de sistemas de ficheros en un zpool

Cifrado de

Con Oracle Solaris, la capacidad de cifrado en ZFS se encaja en la tubería de I/O. Durante la escritura, un bloque puede ser comprimido, cifrado, checksum y luego desduplicados, en ese orden. La política de cifrado se establece a nivel de dataset cuando se crean conjuntos de datos (sistemas de archivos o ZVOLs). Las llaves de ajuste proporcionadas por el usuario o administrador pueden cambiarse en cualquier momento sin tener el sistema de archivos sin conexión. El comportamiento por defecto es el embalaje es crucial ser heredados por los conjuntos de datos de cualquier niño. Las claves de cifrado de datos se generan aleatoriamente en el momento de la creación de conjuntos de datos. Sólo conjuntos de datos descendientes (copias instantáneas y clones) compartan las claves de cifrado de datos. Se proporciona un comando para cambiar a una nueva clave de cifrado de datos para la copia o en cualquier momento, esto no volver a cifrar los datos ya existentes, en lugar de otro utilizan un mecanismo de llave maestra cifrado.

Otras características

Agrupaciones de almacenamiento

A diferencia de los tradicionales sistemas de archivos que residen en los dispositivos individuales y por tanto, requiere un administrador de volúmenes con más de un dispositivo, los sistemas de archivos ZFS se construyen encima de piscinas de almacenamiento de información virtual llamados zpools. Un zpool está construido de dispositivos virtuales (VDEVs), se construye de dispositivos de bloque: Archivos, disco duro particiones, o unidades de todas, con el último siendo el uso recomendado. Dispositivos de bloque dentro de un vdev pueden configurarse de diferentes maneras, dependiendo de las necesidades y espacio disponible: no redundante (similar a la RAID 0), como un espejo (RAID 1) de dos o más dispositivos, como un RAID-Z Grupo de tres o más dispositivos, o como un grupo de cuatro o más dispositivos de RAID-Z2 (similar a RAID-6). En julio de 2009, añadió triple paridad RAID-Z3 para OpenSolaris. RAID-Z es una tecnología de protección de datos de ZFS para reducir el bloque de arriba en espejado.

Así, un zpool (agrupación de almacenamiento ZFS) es vagamente similar a la RAM de una computadora. La capacidad total de la piscina de RAM depende de la cantidad de palillos de la memoria RAM y el tamaño de cada palo. Asimismo, un zpool consta de vdevs uno o más. Cada vdev puede verse como un grupo de discos (o particiones, o archivos, etcetera). Cada vdev debe tener redundancia, de lo contrario si un vdev se pierde, entonces la zpool todo se pierde. Así, cada vdev debe estar configurado como RAID-Z1, RAID-Z2, espejo, etcetera. No es posible cambiar el número de discos de vdev existente (bloque puntero reescribir permite esto y también permite la desfragmentación), pero siempre es posible aumentar la capacidad de almacenamiento mediante la adición de un vdev nuevo a un zpool. Es posible cambiar a coche más grande y de resilver (reparación) zpool. Si se repite este procedimiento para cada disco en un vdev, zpool se crece en capacidad cuando la última unidad es Loggin. Un vdev tendrá la misma capacidad de base como la unidad más pequeña en el grupo. Por ejemplo, un vdev consisten en tres de 500 GB y un disco de 700 GB, tendrá una capacidad de 4 × 500 GB.

Además, piscinas pueden tener repuestos calientes para compensar su defecto discos. Cuando espejado, dispositivos de bloque pueden agruparse según chasis física, para que el sistema de archivos puede seguir en el caso de la falta de un chasis entero.

Composición de la piscina de almacenamiento de información no se limita a dispositivos similares, pero puede consistir en ad-hoc, colecciones heterogéneas de dispositivos, que ZFS piscinas perfectamente juntos, repartiendo posteriormente el espacio para diversos sistemas de ficheros según sea necesario. Tipos de dispositivos de almacenamiento arbitrario se pueden agregar a las piscinas existentes para ampliar su tamaño.

La capacidad de almacenamiento de todos los vdevs está disponible para todas las instancias del sistema de archivo en el zpool. Un cuota puede ser fijados para limitar la cantidad de espacio que puede ocupar una instancia de sistema de archivo, y una Reserva puede establecerse para garantizar que habrá espacio para una instancia de sistema de archivo.

Mecanismos de almacenamiento en caché: arco (L1), L2ARC, grupos de transacciones, SLOG (ZIL)

ZFS utiliza diferentes capas de la memoria caché de disco velocidad de lectura y escribir operaciones. Idealmente, todos los datos deben almacenarse en la memoria RAM, pero que generalmente es demasiado caro. Por lo tanto, datos automáticamente almacena en caché en una jerarquía para optimizar el costo de rendimiento vs. Datos de acceso frecuente se almacenará en la memoria RAM y menos datos de acceso frecuente se pueden almacenar en medios más lentos, como unidades de estado sólido (SSD). Datos que no se accede con frecuencia no se almacena en caché y dejó en los discos duros lentos. Si los datos antiguos de repente es leer mucho, ZFS moverá automáticamente a los SSD o RAM.

Mecanismos de almacenamiento en caché de ZFS incluyen uno para lecturas y escrituras, y en cada caso, pueden existir dos niveles de caché, uno en la memoria de la computadora (RAM) y almacenamiento rápido (generalmente unidades de estado sólido (SSD)), para un total de cuatro escondites.

	Donde almacena	Lectura de memoria caché	Memoria caché de escritura
Caché nivel primera	En la memoria RAM	Conocido como ARCO, debido a su uso de una variante de la caché de recambio adaptable Algoritmo (ARC). Siempre se utilizará la RAM para almacenamiento en caché, por lo tanto este nivel siempre está presente. La eficiencia del arco algoritmo de significa que los discos a menudo no necesitará tener acceso, proporciona el tamaño del arco es suficientemente grande. Si la RAM es muy pequeño apenas habrá cualquier arco en este caso, ZFS siempre debe acceder a los discos subyacentes que afecta considerablemente el performance.	Manejado por medio de "grupos de transacciones" -escribe es recogidos en un período corto (normalmente 5-30 segundos) hasta un límite determinado, con cada grupo se escriben en disco idealmente mientras el siguiente grupo es ser cotejado. Esto permite escribe a organizar más eficientemente los discos subyacentes a riesgo de pérdida de datos de menores de las transacciones más recientes sobre energía interrupción o hardware falla. En la práctica que se evita el riesgo de pérdida de energía por ZFS escribir llevar un diario y por la caché de escritura del SLOG/ZIL segundo nivel piscina (véase abajo), por lo que escribe solo se perderá si un fallo de escritura sucede al mismo tiempo como una pérdida total de la segunda piscina SLOG de nivel, y entonces sólo cuando ajustes relacionados con sincrónico escritura y SLOG uso se establecen en una forma que permitiera tal situación para presentarse. Si se reciben más rápido que se puede escribir datos, recibo de los datos está en pausa hasta que los discos pueden ponerse al día.
Caché de nivel segunda	En dispositivos de almacenamiento rápido (que pueden ser añadidos o eliminados de un sistema "vivo" sin interrupción en las versiones actuales de ZFS, aunque no siempre en versiones anteriores)	Conocido como L2ARC ("nivel 2 ARC"), opcional. ZFS almacenará en caché todos los datos en L2ARC como sea posible, que pueden ser decenas o cientos de gigabytes en muchos casos. L2ARC se acelere también considerablemente deduplicación Si la tabla de deduplicación todo puede ser cacheada en L2ARC. Puede tomar varias horas para rellenar completamente la L2ARC de vacío (antes de ZFS ha decidido que los datos están "calientes" y deben ser almacenado en caché). Si el dispositivo L2ARC se pierde, todas las lecturas se apagarán a los discos que ralentiza el rendimiento, pero nada va a pasar (no hay datos se perderán).	Conocido como SLOG o ZIL ("ZFS registro de intentos de"), opcional pero un SLOG se creará en los dispositivos de almacenamiento principal siempre que ningún dispositivo de caché. Esta es la caché de escritura de segundo nivel y es a menudo mal entendida. Estrictamente hablando, ZFS no utiliza el dispositivo SLOG a caché de que su disco escribe. Por el contrario, utiliza SLOG para escribe es capturados en un medio de almacenamiento permanente tan pronto como sea posible, para que en caso de pérdida o escritura de apagón, no hay datos que fue reconocidos como escrito, se pierde. El dispositivo SLOG permite ZFS rápidamente almacenar escribe y luego como a los dispositivos de almacenaje principal piscina informe. En el curso normal de la actividad, el SLOG nunca ser sucesivo o leer y por lo tanto no actúa como una caché; su finalidad es salvaguardar datos de vuelo durante el tiempo tomado para colación y la escritura, en caso el escribir eventual fueron al fracaso. Si todo va bien, entonces la piscina de almacenamiento de información se actualizará en algún momento dentro de los próximos 5 a 60 segundos, cuando el actual Grupo de transacción es cotejado y escrito en el disco (véase arriba), momento en el que las escrituras guardadas en el SLOG son simplemente ignoradas y sobrescribir. Si finalmente no la escritura, o el sistema sufre un accidente o falla previniendo su escritura, entonces ZFS puede recrear todas las escrituras que deberían haber tenido lugar de SLOG (la única vez se lee desde) y pueden reparar la pérdida de datos. Esto se vuelve crucial si ocurre un gran número de escrituras síncronas (tales como con ESXi, NFS y algunos bases de datos),. donde el cliente requiere confirmación de escritura exitosa antes de continuar con su actividad; el SLOG permite ZFS confirmar la escritura exitosa mucho más rápidamente que si tuvo que escribir a la tienda principal cada vez, sin el riesgo de engañar al cliente sobre el estado de almacenamiento de datos. Si no hay ningún dispositivo SLOG entonces parte de la piscina de datos principal se utilizará para el mismo fin, aunque esto es más lento. Si el dispositivo de registro, es posible perder las últimas escrituras, por lo tanto el dispositivo de registro debe ser reflejado. En versiones anteriores de ZFS, pérdida del dispositivo de registro puede resultar en pérdida de zpool entera, aunque esto ya no es el caso. Por lo tanto, uno debe actualizar ZFS si planea utilizar un dispositivo de registro separado.

Modelo transaccional Copy-on-write

ZFS utiliza un Copy-on-write transaccional modelo de objetos. Todos los punteros de bloque en el sistema de ficheros contienen un 256-bit suma de comprobación o 256-bit Hash (actualmente una opción entre Fletcher-2, Fletcher-4, o SHA-256) del bloque de destino, que se verifica cuando se lee el bloque. Bloques que contienen datos activos nunca se sobrescriben en el lugar; en cambio, se asigna un nuevo bloque, modificado los datos se escriben a él, entonces cualquier metadatos de bloques de referencia Asimismo se leen, reasignado y escrito. Para reducir la sobrecarga de este proceso, varias actualizaciones se agrupan en grupos de transacciones y (ZILregistro de intención) escribir caché se utiliza cuando la semántica sincrónica escribir se requieren. Los bloques se arreglan en un árbol, como son sus sumas de verificación (véase Esquema de firma de MERKLE).

Copias instantáneas y clones

Una ventaja de copia por escritura es que cuando ZFS escribe nuevos datos, los bloques que contienen los datos anteriores pueden ser retenidos, permitiendo un instantánea versión del sistema de archivos que se mantendrán. Instantáneas de ZFS se crean muy rápidamente, ya que todos los datos de composición de la instantánea ya está almacenados. También son espacio eficiente, puesto que los datos sin cambios se compartieron entre el sistema de archivos y sus instantáneas.

También se pueden crear instantáneas pueden escribir ("clones") dando por resultado dos sistemas de archivos independientes que comparten un conjunto de bloques. Como se realizan cambios en cualquiera de los sistemas de archivos de copia, nuevos bloques de datos se crean para reflejar esos cambios, pero cualquier bloques inalterados siguen compartir, no importa cómo muchos clones que existen. Se trata de una implementación de la Copy-on-write principio.

Enviar y recibir fotos

Sistemas de archivos ZFS se pueden mover a otras piscinas, también en los hosts remotos sobre la red, como el comando send crea una representación de la corriente del estado del sistema de archivos. Esta corriente tampoco puede describir contenido completo del sistema de archivos en una foto determinada, o puede ser un delta entre las instantáneas. Informática la secuencia delta es muy eficiente, y su tamaño depende del número de bloques cambió entre las instantáneas. Esto proporciona una estrategia eficiente, por ejemplo, para sincronizar copias de seguridad fuera del sitio o espejos de alta disponibilidad de una piscina.

Dynamic striping

Dinámica reparto de los en todos los dispositivos para maximizar rendimiento de procesamiento significa que como dispositivos adicionales se agregan a la zpool, el ancho de banda automáticamente se expande para incluir por lo tanto, todos los discos en una piscina se utilizan, que equilibra la carga de la escritura a través de ellas.

Tamaños de bloque variable

ZFS utiliza bloques de tamaño variable, con 128 KB como tamaño por defecto. Funciones disponibles permiten al administrador ajustar el tamaño máximo del bloque que se utiliza, como ciertas cargas de trabajo no se realizan con bloques grandes. Si compresión de datos es habilitado, variable bloque de tamaños. Si un bloque se puede comprimir para caber en un tamaño de bloque más pequeño, el tamaño más pequeño se utiliza en el disco para utilizar menos almacenamiento de información y mejorar el rendimiento de IO (aunque en el coste de mayor uso de CPU para las operaciones de compresión y descompresión).

Creación ligera del filesystem

En ZFS, manipulación de archivos dentro de un grupo de almacenamiento es más fácil que la manipulación de volumen dentro de un sistema de archivos tradicional; el tiempo y esfuerzo necesarios para crear o ampliar un sistema de archivos ZFS está más cerca de hacer un nuevo directorio que es manipulación de volumen en algunos otros sistemas.

Orden de bits adaptable

Piscinas y sus sistemas de archivos ZFS asociados se pueden mover entre las arquitecturas de diferentes plataformas, incluyendo sistemas de ejecución de órdenes de bytes diferentes. Las ZFS bloque puntero tiendas de formato sistema de archivos metadatos en un endian-modo adaptativo; bloques de metadatos individuales se escriben con el orden de bytes nativo del sistema escribir el bloque. Al leer, si el orden de bits almacenada no coincide con el orden de bits del sistema, los metadatos están intercambio de bytes en la memoria.

Esto no afecta los datos almacenados; como es costumbre en POSIX sistemas de archivos aparecen aplicaciones como simples arrays de bytes, para que aplicaciones de creación y lectura de datos siendo responsables para hacerlo de manera independiente de la orden de bits de sistema subyacente.

Deduplicación

Desduplicación de datos capacidades fueron agregadas para el repositorio de origen ZFS a finales de octubre de 2009, y paquetes de desarrollo de OpenSolaris ZFS relevantes han estado disponibles desde 03 de diciembre de 2009 (build 128).

Uso eficaz de la deduplicación puede requerir gran capacidad de memoria RAM; gama de recomendaciones entre 1 y 5 GB de RAM para cada TB de almacenamiento. Memoria física insuficiente o falta de memoria caché ZFS puede resultar en memoria virtual golpear cuando usando deduplicación, que puede bajar el rendimiento o causar hambre de memoria completa. Unidades de estado sólido (SSD) puede ser utilizado para almacenar tablas de desduplicación, tal modo acelerar el rendimiento de desduplicación.

Otros proveedores de almacenamiento de información utilizan versiones modificadas de ZFS para alcanzar muy altas relaciones de compresión de datos. Dos ejemplos en 2012 fueron GreenBytes y Tegile. En mayo de 2014, Oracle compró GreenBytes por su tecnología de deduplicación y replicación de ZFS.

Capacidades adicionales

• Prioridad de I/O explícita con deadline scheduling.
• Afirmó la agregación y clasificación de I/O globalmente óptima.
• Independiente de múltiples arroyos con automático de la longitud de búsqueda y detección del paso.
• Operaciones de directorio paralelo, tiempo constante.
• Sumas de comprobación de end-to-end, usando una especie de "Campo de integridad de datos", lo que permite la detección de corrupción de datos (y si tiene redundancia en la piscina de recuperación).
• Compresión de ficheros transparente. Soportes LZJB, gzip y LZ4.
• Inteligente de limpieza y actualizar la duplicación de (resincronizando).
• Uso de carga y espacio compartido entre los discos en la piscina.
• Lo mismo manzanas: replicación de datos Configurable por el sistema de archivos, con cero, uno o dos ejemplares adicionales solicitados por escritura para datos de usuario y con ese mismo número base de copias más uno o dos para metadatos (según importancia de metadatos). Si la piscina tiene varios dispositivos, ZFS intenta replicar a través de diferentes dispositivos. Ídem bloques son sobre todo una protección adicional contra sectores dañados, no contra la falla de disco total.
• Diseño ZFS (copy-on-write + superblocks) es seguro al usar discos con memoria caché de escritura habilitada, si honran las barreras de la escritura. Esta característica proporciona seguridad y una mejora en el rendimiento en comparación con algunos otros sistemas de archivos.
• En Solaris, cuando se agregan discos completos a una agrupación ZFS, ZFS permite automáticamente su caché de escritura. Esto no se hace cuando ZFS sólo segmentos discretos del disco, ya que no se sabe si otras rebanadas son gestionados por la caché de escritura no seguro sistemas de ficheros, como UFS. La aplicación de FreeBSD puede manejar descargas disco de particiones gracias a su GEOM marco y por lo tanto no sufren esta limitación.
• Cuotas por usuario y por grupo de apoyo.
• Sistema de archivos cifrado desde Solaris 11 Express.
• Piscinas pueden ser importadas en modo de sólo lectura.
• Es posible recuperar los datos por deshaciendo todas transacciones en el momento de importar la zpool.
• ZFS no es un sistema de archivos Cluster; sin embargo, agrupado ZFS está disponible por parte de terceros.
• Las instantáneas pueden tomarse manualmente o automáticamente. Las versiones anteriores de datos almacenados que contienen pueden estar expuestas a los sistemas de cliente a través de CIFS (también conocido como SMB/Samba y utilizado por Microsoft Windows archivos compartidos) como "Versiones anteriores", "Instantáneas VSS" o "Historia del archivo", y AFP (para dispositivos Apple) como "Apple Time Machine".

Limitaciones

Limitaciones en la prevención de daños en los datos

Un libro de 2010 examine la capacidad de los sistemas de archivos para detectar y prevenir la corrupción de datos, observa que ZFS sí es eficaz en la detección y corrección de errores de datos en dispositivos de almacenamiento, pero que asume los datos en MEMORIA RAM son "seguros" y no propenso a errores. Así cuando ZFS almacena en memoria caché páginas tiendas copias de metadatos en la memoria RAM, o tiene datos de su "sucia" caché de escritura en disco, ninguna prueba es si los checksums coinciden todavía los datos en el punto de uso. Gran parte de este riesgo puede ser mitigado por el uso de ECC RAM pero los autores consideran que la detección de errores relacionados con la caché de páginas y montón permitiría ZFS manejar ciertos tipos de error más robusta.

Que señalan los autores de un estudio dedicado íntegramente a la integridad de datos ZFS "flip [...] un poco solo en la memoria causa un porcentaje pequeño pero no despreciable de funcionamientos a experimentar un fracaso", con la probabilidad de cometer malos datos en el disco varía de 0% a 3,6% (según la carga de trabajo).

Limitaciones específicas de ZFS

• Ampliación de la capacidad se logra normalmente mediante la adición de grupos de discos como un vdev de nivel superior: dispositivo simple, RAID-Z, Z2 RAID, RAID 3 o espejado. Recién escritos datos dinámicamente comenzará a utilizar todos los vdevs disponibles. También es posible ampliar la matriz cambiando iterativamente cada unidad de la matriz con un coche más grande y esperando para ZFS self-heal; el tiempo de sanación dependerá de la cantidad de información almacenada, no el tamaño del disco.
• A partir de Solaris 10 Update 11 y Solaris 11.2, es ni posible para reducir el número de nivel superior vdevs en una piscina, ni para reducir la capacidad de la piscina. Esta funcionalidad se decía que era en el desarrollo ya en 2007.
• No es posible añadir un disco como una columna a un vdev RAID Z, RAID Z2 o Z3 RAID. Sin embargo, un nuevo vdev RAID Z puede estar en su lugar y se agrega al zpool.
• Algunas configuraciones de RAID anidados tradicionales, tales como RAID 51 (un espejo de RAID 5 grupos), no son configurables en ZFS. VDEVs sólo puede estar compuesta de discos raw o archivos, no otros vdevs. Sin embargo, una agrupación ZFS efectivamente crea una banda (RAID 0) a través de su vdisp, por el equivalente de un RAID 50 o 60 de RAID es común.
• Configurar el número de dispositivos en un vdev de nivel superior requiere copia de datos fuera de línea, destruyendo la piscina y recreando la piscina con la nueva configuración de vdev de nivel superior, excepto para agregar redundancia adicional a un espejo existente, que puede hacerse en cualquier momento o si todos los vdevs de nivel superior son espejos con redundancia suficiente divide el zpool comando puede utilizarse para eliminar una vdev de cada vdev de nivel superior en el grupo, crear un grupo de 2 º con datos idénticos.
• Resilver (reparación) de un disco se estrelló en un RAID de ZFS puede tomar mucho tiempo (esto no es exclusivo a ZFS, se aplica a todos los tipos de RAID, en una forma u otra). Esto significa que volúmenes muy grandes pueden tomar varios días para reparar o a redundancia completa después de datos graves daños o fallas y durante este tiempo un segundo disco falla puede ocurrir, sobre todo porque la reparación pone tensión adicional en el sistema como un todo. Esto significa que se deben evitar las configuraciones que sólo permiten la recuperación de un fallo de disco, como RAID Z1 (similar a RAID 5). Por lo tanto, con grandes discos, uno debe utilizar RAID Z2 (permite dos discos a crash) o RAID Z3 (permiten tres discos al accidente). Sin embargo, cabe señalar que ZFS RAID difiere de la convencional RAID sólo reconstruyendo metadatos y datos en tiempo real cuando se reemplace un disco, no la totalidad del disco como en blanco y bloques de basura, lo que significa que reemplazar un disco de miembro en una agrupación ZFS que es sólo parcialmente llena llevará mucho menos tiempo en comparación con a RAID convencional.
• IOPS funcionamiento de una agrupación de almacenamiento ZFS puede sufrir si la incursión ZFS no se configura apropiadamente. Esto se aplica a todos los tipos de RAID, en una forma u otra. Si la zpool consiste en solamente un grupo de discos configurados como, digamos, ocho discos en RAID Z2, entonces el rendimiento de IOPS será de un solo disco (leído será equivalente a 8 discos, pero la velocidad de escritura será similar a un único disco). Sin embargo, hay maneras de mitigar este problema de rendimiento de IOPS, agregar por ejemplo SSD como caché L2ARC — que puede impulsar la IOPS en 100.000s. En definitiva, un zpool debe consistir en varios grupos de vdevs, cada vdev consisten en discos de 8 a 12, si utiliza RAID Z. No se recomienda crear un zpool con una sola gran vdev, decir 20 discos, porque el rendimiento de IOPS será de un solo disco, que también significa que resilver tiempo será muy largo (posiblemente semanas con futuras unidades grandes).
• Encogimiento en línea no es compatible.

Plataformas

Solaris

Solaris 10 update 2 y más tarde

ZFS es parte del sistema de operativo de Solaris del Sun y por lo tanto está disponible en ambos SPARC y x86-sistemas basados.

Solaris 11

Después Solaris 11 Express versión de Oracle, la consolidación de OS/Net (código OS principal) se hizo propietario y cerrado-fuente, y más actualizaciones ZFS y las implementaciones dentro de Solaris (como el cifrado) no son compatibles con otras implementaciones de no-propietario que utilizan versiones anteriores de ZFS.

Al crear una nueva agrupación ZFS, reteniendo la capacidad para utilizar el acceso a la piscina de otras distribuciones basadas en Solaris no propietaria, se recomienda actualizar a Solaris 11 Express de OpenSolaris (snv_134b), y así permanecer en ZFS versión 28.

OpenSolaris

OpenSolaris 2008.05, 2008.11 y 2009.06 utilizar ZFS como su sistema de archivos por defecto. Hay más de una docena 3rd-party distribuciones, de que casi una docena se mencionan aquí. (OpenIndiana y IllumOS son dos distribuciones nuevo no incluidas en la página de referencia de distribución de OpenSolaris).

OpenIndiana

OpenIndiana usa OpenZFS con banderas de la característica como se implementó en IllumOS. ZFS versión 28 hasta versión 151a3.

Realizar una actualización de OpenSolaris snv_134 OpenIndiana y Solaris 11 Express, uno también tiene la capacidad de actualizar y por separado de arranque de Solaris 11 Express en la misma agrupación ZFS, pero uno debe no instalar Solaris 11 Express primero debido a incompatibilidades ZFS introducidas por Oracle pasado ZFS versión 28.

BSD

macOS

OpenZFS en OSX (abreviado a O3X) es una implementación de ZFS para macOS. O3X está bajo desarrollo activo, con estrecha relación a ZFS en Linux y la implementación de sistemas de illumos, mientras mantiene la característica bandera compatibilidad con ZFS en Linux. O3X implementa zpool versión 5000 e incluye el Solaris portar capa (SPL) originalmente creado por MacZFS, que se ha mejorado aún más para incluir una capa de gestión de memoria basada en el distribuidor de kmem y vmem illumos. O3X aparece completamente, apoyando LZ4 compresión, deduplicación, arco, L2ARC y SLOG.

MacZFS es software libre, proporcionando soporte para ZFS en macOS. La rama estable de legado proporciona hasta la versión 8 de pool ZFS y ZFS filesystem versión 2. La rama de desarrollo, basada en ZFS en Linux y OpenZFS, proporciona funcionalidad ZFS actualizada, como hasta ZFS zpool versión 5000 y banderas de la característica.

Una implementación propietaria de ZFS (Zevo) estaba disponible sin costo de GreenBytes, Inc., ejecución hasta la versión 5 del sistema de archivos ZFS y ZFS pool versión 28. Zevo ofrece un conjunto de características ZFS limitado, pendientes de mayor desarrollo comercial; fue vendido a Oracle en el 2014, con planes para el futuro desconocidos.

DragonFlyBSD

Edward O'Callaghan comenzó el puerto inicial de ZFS a DragonFlyBSD.

NetBSD

El puerto de NetBSD ZFS se inició como parte del 2007 Google Summer of Code y en agosto de 2009, el código se fusionó con NetBSDdel árbol de código fuente.

FreeBSD

Pawel Jakub Dawidek portado ZFS a FreeBSD, y ha sido parte de FreeBSD desde la versión 7.0. Esto incluye ZFSArranque, que permite arrancar FreeBSD directamente desde un volumen de ZFS.

Implementación de sistemas de FreeBSD es totalmente funcional; las únicas características que faltan son el núcleo CIFS servidor y iSCSI, pero este último se puede Agregar usando los paquetes disponibles externamente. Samba puede utilizarse para proporcionar un servidor CIFS de espacio de usuario.

FreeBSD 7-STABLE (donde las actualizaciones de la serie de versiones 7.x están comprometidos a) utiliza zpool versión 6.

FreeBSD 8 incluye una implementación muy actualizado de ZFS, y soporte zpool versión 13. zpool versión 14 soporte se añadió a la rama estable de 8 a 11 de enero de 2010, y se incluye en FreeBSD versión 8.1. zpool versión 15 es compatible con la versión 8.2. La rama STABLE 8 obtuvo apoyo de zpool versión v28 y zfs versión 5 a principios de junio de 2011. Estos cambios fueron liberados a mediados de abril de 2012 con FreeBSD 8.3.

FreeBSD versión de ZFS de 9,0-lanzamiento usa 28.

9.2 distribución FreeBSD-es la primera versión de FreeBSD con la nueva implementación de "banderas de la característica" base así piscina versión 5000.

MidnightBSD

MidnightBSD, un sistema operativo de escritorio derivado de FreeBSD, admite ZFS versión piscina de almacenamiento 6 a partir de la versión 0.3. Esto se derivó del código incluido en FreeBSD 7.0-RELEASE. Una actualización de grupo de almacenamiento 28 está en curso en 0.4-corriente y basado en fuentes 9-estable alrededor de FreeBSD 9,1-código.

TrueOS

TrueOS (anteriormente conocido como PC-BSD) es una distribución orientada al escritorio de FreeBSD, que hereda su apoyo ZFS.

FreeNAS

FreeNAS, un integrado de código abierto almacenamiento de información conectado en red Distribución (NAS) basado en FreeBSD, tiene el mismo ZFS como FreeBSD y PC-BSD.

Gurú de ZFS

Gurú de ZFS, un integrado de código abierto almacenamiento de información conectado en red Distribución (NAS) basado en FreeBSD, bajo desarrollo activo.

pfSense y PCBSD

pfSense, un software libre basado en BSD router, y PCBSD, un escritorio basado en BSD, ambos soportan ZFS (pfSense en su próxima versión 2.4).

NAS4Free

NAS4Free, un integrado de código abierto almacenamiento de información conectado en red Distribución (NAS) basado en FreeBSD, tiene el mismo ZFS como FreeBSD, versión de piscina de almacenamiento ZFS 5000. Este proyecto es una continuación del proyecto de la serie 7 de FreeNAS.

Debian GNU/kFreeBSD

Está basado en el kernel de FreeBSD, Debian GNU/kFreeBSD tiene soporte desde el núcleo de ZFS. Sin embargo, herramientas de entorno de usuario adicional se requiere, Si bien es posible que ZFS como sistema de archivos root o boot en cuyo caso se requiere GRUB configuración se realiza por el instalador de Debian desde la Sibilancias lanzamiento.

A partir del 31 de enero de 2013, la versión de ZPool disponible es de 14 para la Squeeze liberación y 28 para el Wheezy-9 lanzamiento.

Linux

Aunque es compatible con el sistema de archivos ZFS Linux-basado en sistemas operativos, dificultades para Distribución de Linux desarrolladores que deseen proporcionar soporte nativo para ZFS en sus productos debido a potenciales incompatibilidades legales entre el CDDL licencia utilizada por el código ZFS y la GPL licencia utilizada por el kernel de Linux. Para habilitar el soporte ZFS en Linux, un módulo del núcleo de loadable que contiene el código de licencia CDDL ZFS debe ser compilado y cargado en el kernel. Según el Free Software Foundation, el texto de la licencia GPL prohíbe legalmente la redistribución del producto resultante como un trabajo derivado, Aunque este punto de vista ha provocado cierta controversia.

ZFS en fusible

Una potencial solución a incompatibilidad de licencias fue exitosa en 2006, con un puerto experimental del código ZFS en Linux FUSIBLE sistema. El sistema de archivos funcionó enteramente en espacio de usuario en lugar de ser integrado en el kernel de Linux y por lo tanto no era considerado un trabajo derivado del núcleo. Este enfoque era funcional, pero sufrían penas de considerable en el rendimiento en comparación con la integración del sistema de archivos como un módulo del kernel nativo en espacio de kernel. A partir de 2016, ZFS en proyecto fusible aparece ser difunto.

ZFS nativo en Linux

Un puerto nativo de ZFS para Linux producida por la Lawrence Livermore National Laboratory (LLNL) fue lanzado en marzo de 2013, estos acontecimientos clave:

• 2008: prototipo para determinar viabilidad
• 2009: ZVOL inicial y el Lustre de la ayuda
• 2010: desarrollo a GitHub
• 2011: POSIX capa de agregado
• 2011: comunidad de los adoptadores tempranos
• 2012: uso de la producción de ZFS
• 2013: estable GA lanzamiento

A partir de agosto de 2014, ZFS en Linux utiliza el OpenZFS piscina de número de versión 5000, que indica que las características que soporta se definen a través de banderas de la característica. Esta versión de piscina es un invariable número que se espera nunca en conflicto con los números de versión dados Oracle.

KQ InfoTech

Otro puerto nativo para Linux fue desarrollado por InfoTech KQ en 2010. Este puerto se utiliza el zvol implementación del laboratorio nacional Lawrence Livermore como punto de partida. Un comunicado de apoyo zpool V28 fue anunciado en enero de 2011. En abril de 2011, KQ Infotech fue adquirida por sTec, Inc., y su trabajo en ZFS. Código fuente de este puerto se puede encontrar en GitHub.

El trabajo de KQ InfoTech fue integrado en última instancia en Puerto nativo de ZFS del LLNL para Linux.

Distribución de código fuente

Mientras que la incompatibilidad de la licencia puede surgir con la distribución de binarios compilados que contiene código de ZFS, es generalmente aceptado que la distribución del código fuente sí mismo no es afectado por esto. En Gentoo, configurando un sistema de archivos root ZFS está bien documentada y pueden instalar los paquetes requeridos de su repositorio de paquetes. Slackware también proporciona documentación sobre ZFS, tanto como un módulo del núcleo de apoyo y cuando está integrado en el kernel.

Integración de Ubuntu

La cuestión de la compatibilidad de la licencia CDDL con licencia GPL resurgió en el año 2015, cuando la distribución de Linux Ubuntu anunció que la intención de hacer módulos de kernel binario OpenZFS precompilados para los usuarios finales directamente desde los repositorios oficiales de la distribución. En 2016, Ubuntu anunció que una revisión legal dio lugar a la conclusión de proporcionando soporte para ZFS via un binario módulo del núcleo no estaba en violación de las disposiciones de la licencia GPL. Otros siguieron conclusión de Ubuntu, mientras que la FSF y el SFC reiteraron su opinión de oposición.

Ubuntu 16.04 LTS "(Xerus Xenial del), lanzado el 21 de abril de 2016, permite al usuario instalar los paquetes binarios de OpenZFS directamente desde los repositorios de software de Ubuntu. A partir de abril de 2017, no se ha señalado ningún desafío legal contra Canónico en cuanto a la distribución de estos paquetes.

Lista de sistemas operativos, soporte a ZFS

Lista de sistemas operativos, distribuciones y Add-ons que ZFS, la versión de zpool que es compatible y la versión de Solaris que se basan en (si existe):

OS	Versión de zpool	# Construcción de Sun/Oracle	Comentarios
Oracle Solaris 11.3	37	0.5.11-0.175.3.1.0.5.0
Oracle Solaris 10 1/13 (U11)	32
Oracle Solaris 11.2	35	0.5.11-0.175.2.0.0.42.0
Oracle Solaris 11 2011.11	34	B175
Oracle Solaris Express 11 2010.11	31	b151a	licencia para pruebas solamente
OpenSolaris 2009.06	14	b111b
OpenSolaris (último dev)	22	b134
OpenIndiana	5000	B147	OpenIndiana crea un conflicto de nombre con su b151a de código de nombres
Nexenta Base 3.0.1	26	b134 +	GNU userland
NexentaStor Comunidad 3.0.1	26	b134 +	hasta 18 TB, web admin
NexentaStor Comunidad 3.1.0	28	b134 +	GNU userland
NexentaStor Comunidad 4.0	5000	b134 +	hasta 18 TB, web admin
NexentaStor empresa	28	b134 +	no gratis, web admin
GNU/kFreeBSD "Apriete" (a partir del 31/01/2013)	14		Requiere el paquete "zfsutils"
GNU/kFreeBSD «Wheezy-9"(a partir del 21/02/2013)	28		Requiere el paquete "zfsutils"
FreeBSD	5000
ZFS-fuse 0.7.2	23		sufrió de problemas de performance; ya desaparecida
ZFS en Linux 0.6.5.8	5000		0.6.0 versión candidata tiene capa POSIX
KQ Infotech ZFS en Linux	28		ya desaparecida; código integrado en LLNL admite ZFS en Linux
BeleniX 0.8b1	14	B111
Schillix 0.7.2	28	B147
StormOS "granizo"			basado en Nexenta
Jaris			Japonés
MilaX 0.5	20	b128a	tamaño pequeño
FreeNAS 8.0.2 / 8.2	15
FreeNAS 8.3.0	28		basado en FreeBSD 8.3
FreeNAS 9.1.0	5000		basado en FreeBSD 9.1
NAS4Free 10.2.0.2/10.3.0.3	5000		basado en FreeBSD 10.2/10.3
Korona 4.5.0	22	b134	KDE
NAS de EON (v0.6)	22	B130	NAS integrado
NAS de EON (v1.0beta)	28	b151a	NAS integrado
Napp-it	28/5000	IllumOS / Solaris	Dispositivo de almacenamiento con interfaz de usuario Web para OpenIndiana (Hipster), OmniOS, 11 Solaris o Linux (administración de ZFS)
OmniOS	28/5000	rama de IllumOS omnios	distribución de servidor de almacenaje mínimo basado en Illumos
SmartOS	28/5000	IllumOS b151 +	mínima distribución live basada en Illumos (cargadores de CD/USB) adecuado para el uso de nube e hipervisor (KVM)
macOS 10.5, 10.6, 10.7, 10.8 y 10.9	5000		MacZFS
macOS 10.6, 10.7 y 10.8	28		ZEVO
NetBSD	22
MidnightBSD	6
Ubuntu 16.04 LTS	5000		ofrece soporte nativo a través del módulo binario instalable
ZFSGuru 10.1.100	5000

Historia

ZFS fue diseñado e implementado por un equipo liderado por Sun Jeff Bonwick, Bill Moore y la Mateo Ahrens. Fue anunciado el 14 de septiembre de 2004, pero desarrollo comenzó en 2001. Código fuente para ZFS fue integrado en el tronco principal de desarrollo de Solaris el 31 de octubre de 2005 y lanzado como parte del build 27 de OpenSolaris en 16 de noviembre de 2005. Sun anunció que ZFS fue incluido en la actualización del 6/06 Solaris 10 en junio de 2006, un año después de la apertura de la comunidad de OpenSolaris.

El nombre en un momento se dijo que representan "Zettabyte File System", pero en 2006 ya no era considerada ser una abreviatura. Un sistema de archivos ZFS puede almacenar hasta 256000 trilloneszettabytes (ZB).

En septiembre de 2007, NetApp demandó el sol alegando que ZFS infringido algunas de las patentes de NetApp en Escriba en cualquier estructura de ficheros. El sol en demandó en octubre del mismo año alegando lo contrario. Los pleitos se terminaron en 2010 con un acuerdo no revelado.

Implementaciones de código abierto

La siguiente es una lista de eventos en el desarrollo de implementaciones de sistemas de código abierto:

• 2005: código fuente fue liberado como parte de OpenSolaris.
• 2006: desarrollo de un Puerto de fusible para Linux comenzó.
• 2007: Apple comenzaron a portar ZFS a Mac OS X.
• 2008: un puerto para FreeBSD fue lanzado como parte de FreeBSD 7.0.
• 2008: desarrollo de un Puerto nativo de Linux comenzó.
• 2009: proyecto ZFS de manzana cerrada. El MacZFS proyecto continuó desarrollando el código.
• 2010: OpenSolaris fue continuado. Desarrollo de ZFS en Solaris ya no era de código abierto.
• 2010: IllumOS fue fundada como un sucesor de código abierto, y continuo desarrollo de ZFS al aire libre. Puertos de ZFS a otras plataformas continuaron migración aguas arriba cambia de illumos.
• 2013: el OpenZFS proyecto comienza, con el objetivo de desarrollo coordinado de la abrir-fuente de ZFS.

Uso en productos comerciales

• 2008: el sol envía una línea de dispositivos de almacenamiento serie 7000 basada en ZFS.
• 2013: oracle envía ZS3 serie de sistemas de almacenamiento basados en ZFS y agarró el primer lugar en la SPC-2 de referencia con uno de ellos.
• 2013: iXsystems naves de dispositivos NAS basada en ZFS llamados FreeNAS para SOHO y TrueNAS para la empresa.
• 2014: Netgear naves llamada de una línea de dispositivos NAS basada en ZFS ReadyDATA, diseñado para ser utilizado en la empresa.

Historia detallada del lanzamiento

Con ZFS en Solaris Oracle: nuevas características son introducidas, se incrementan los números de versión del sistema piscina y archivo para designar el formato y características disponibles. Características que están disponibles en versiones de sistema de archivos específico requieren una versión específica de la piscina.

Implica el desarrollo distribuido de OpenZFS banderas de la característica y versión piscina 5000, un número inmutable que se espera nunca en conflicto con los números de versión de Oracle. Números de versión legado todavía existen para las versiones de pool 1 – 28, implícita en la versión 5000. IllumOS utiliza versión piscina 5000 para este propósito. Cambios de formato en el disco futuro son activados / desactivados independientemente a través de indicadores de función.

Leyenda:

Versión antigua

Más reciente SOFTWARE LIBRE versión estable

Última versión estable patentada

Última versión de beta propiedad

Número de versión de sistema de archivos ZFS	Fecha de lanzamiento	Cambios significativos
1	Nevada de OpenSolaris construir 36	Primera versión
2	OpenSolaris Nevada b69	Mejorado las entradas de directorio. En particular, las entradas de directorio ahora almacenan el tipo de objeto. Por ejemplo, archivo, directorio, nombre pipa y así sucesivamente, además del número de objeto.
3	OpenSolaris Nevada b77	Soporte para compartir sistemas de archivos ZFS sobre SMB. Apoyo de la insensibilidad del caso. Sistema de ayuda de atributo. Soporte de antivirus integrado.
4	OpenSolaris Nevada b114	Propiedades: userquota, groupquota, userused y groupused
5	OpenSolaris Nevada b137	Atributos del sistema; los enlaces simbólicos ahora su propio objeto tipo
6	11.1 de Solaris	Soporte de sistema de archivos multinivel

Número de versión de Pool ZFS	Fecha de lanzamiento	Cambios significativos
1	Nevada de OpenSolaris B36	Primera versión
2	OpenSolaris Nevada b38	Lo mismo manzanas
3	OpenSolaris Nevada b42	Repuestos en marcha, paridad doble RAID-Z (raidz2), mejorado contabilidad RAID-Z
4	OpenSolaris Nevada b62	historia de zpool
5	OpenSolaris Nevada b62	compresión gzip para conjuntos de datos ZFS
6	OpenSolaris Nevada b62	propiedad "bootfs de la agrupación"
7	OpenSolaris Nevada b68	ZIL: añade la capacidad para especificar un dispositivo de registro de intentos separado o dispositivos
8	OpenSolaris Nevada b69	capacidad de delegar tareas administrativas zfs(1M) a los usuarios normales
9	OpenSolaris Nevada b77	Soporte CIFS en el servidor, conjunto de datos contingentes
10	OpenSolaris Nevada b77	Dispositivos se pueden agregar a una piscina de almacenamiento de información como "dispositivos de caché"
11	OpenSolaris Nevada b94	Mejor zpool scrub / resilver rendimiento
12	OpenSolaris Nevada b96	Propiedades de instantáneas
13	OpenSolaris Nevada b98	Propiedades: usedbysnapshots, usedbychildren, usedbyrefreservation y usedbydataset
14	OpenSolaris Nevada b103	soporte de propiedad aclinherit passthrough-x
15	OpenSolaris Nevada b114	Propiedades: userquota, groupquota, usuerused y groupused; también se requiere FS v4
16	OpenSolaris Nevada b116	Soporte de propiedad STMF
17	OpenSolaris Nevada b120	RAID-Z de paridad triple
18	OpenSolaris Nevada b121	Instantánea ZFS tiene
19	OpenSolaris Nevada b125	Retiro de dispositivo de registro ZFS
20	OpenSolaris Nevada b128	ZLE algoritmo de compresión que se necesita para soportar las propiedades de la deduplicación de ZFS en versión de pool ZFS 21, que fueron lanzados al mismo tiempo
21	OpenSolaris Nevada b128	Deduplicación
22	OpenSolaris Nevada b128	ZFS recibir propiedades
23	OpenSolaris Nevada b135	ZIL delgado
24	OpenSolaris Nevada b137	Atributos del sistema. Enlaces simbólicos ya su propio tipo de objeto. También requiere FS v5.
25	OpenSolaris Nevada b140	Piscina mejor lavado y actualizar la duplicación de las estadísticas
26	OpenSolaris Nevada b141	Rendimiento de eliminación instantánea mejorada
27	OpenSolaris Nevada b145	Rendimiento de creación instantánea mejorada (particularmente recursiva instantáneas)
28	OpenSolaris Nevada b147	Múltiples reemplazos de dispositivo virtual
29	B148 de Solaris Nevada	Asignador de RAID-Z/espejo híbrido
30	B149 de Solaris Nevada	Cifrado de ZFS
31	B150 de Solaris Nevada	Mejor rendimiento 'zfs list'
32	Solaris Nevada b151	Soporte del bloque uno MB
33	B163 de Solaris Nevada	Apoyo de la mayor parte
34	11.1 de Solaris (0.5.11-0.175.1.0.0.24.2)	Compartiendo con herencia
35	11.2 de Solaris (0.5.11-0.175.2.0.0.42.0)	Resilver secuencial
36	11.3 de Solaris	Asignación de bloque de registro eficiente
37	11.3 de Solaris	LZ4 compresión
5000	OpenZFS	Versión de piscina no cambia para indicar que la piscina indica novedades después de piscina versión 28 Banderas de la característica ZFS en lugar de incrementar la versión piscina

Nota: La versión de Solaris bajo desarrollo por Sun desde el lanzamiento de Solaris 10 en el año 2005 fue nombre en clave 'Nevada' y se deriva de lo que fue la OpenSolaris codebase. 'Solaris Nevada' es el nombre en clave para el SO Solaris de próxima generación para finalmente tener éxito Solaris 10 y este nuevo código fue tirado después sucesivamente en nuevo OpenSolaris 'Nevada' instantánea construye. OpenSolaris ahora se interrumpe y OpenIndiana carretillas de horquilla de él. Una versión final (b134) de OpenSolaris fue publicado por Oracle (12-Nov-2010) como una ruta de actualización a Solaris 11 Express.

macOS

La primera indicación de Apple Inc.de interés en ZFS fue un post de abril de 2006 en opensolaris.org zfs-discutir la lista de correo donde un empleado de Apple mencionó estar interesado en portar ZFS a sus Mac OS X Sistema operativo. En la versión de Mac OS X 10.5, ZFS estaba disponible en modo de sólo lectura de la línea de comandos, que carece de la posibilidad de crear zpools o escribir en ellos. Antes de la versión 10.5, Apple lanzó la "semilla ZFS Beta v1.1", que permite acceso de lectura-escritura y la creación de zpools, sin embargo, el instalador de la "semilla ZFS Beta v1.1" se ha reportado que sólo funcionan en la versión 10.5.0 y no ha sido actualizado para la versión 10.5.1 y arriba. En agosto de 2007, Apple ha abierto un proyecto ZFS en su sitio de web de Mac OS Forge. En ese sitio, Apple proporciona el código fuente y binarios de su puerto de ZFS, que incluye el acceso de lectura y escritura, pero no había ningún instalador disponible hasta que un desarrollador de terceros creado uno. En octubre de 2009, Apple anunció un cierre de proyecto ZFS en Mac OS Forge. Es decir que su propio alojamiento y participación en ZFS fue sumariamente continuada. Ninguna explicación fue dada, sólo la siguiente declaración: "se ha suspendido el proyecto ZFS. La lista de correo y el repositorio también se eliminará poco."Apple lanzaría eventualmente la parte legal, derivado de CDDL, del código fuente de su beta pública final de ZFS, código nombrado"10a286". Soporte completo de ZFS una vez fue promocionado como una función de servidor de Snow Leopard (Mac OS X Server 10.6). Sin embargo, cuando que el sistema operativo fue lanzado, todas las referencias a esta característica habían sido silenciosamente quitadas de su página de características. Apple no ha comentado sobre la omisión.

Liberación de código fuente "10a286" de Apple y las versiones de la versión fuente y binarios, se han conservado y nuevo desarrollo ha sido adoptado por un grupo de entusiastas. El proyecto de MacZFS actuó rápidamente para reflejar el archivo público del proyecto de Apple antes de que los materiales habría desaparecido de internet y luego retomar su desarrollo en otros lugares. La comunidad MacZFS ha curado y madurado el proyecto, soporte a ZFS para todas las versiones de Mac OS desde 10.5. El proyecto cuenta con un activo lista de correo. A partir de julio de 2012, MacZFS implementa zpool versión 8 y ZFS versión 2, de octubre de 2008 la liberación de Solaris. Comentarios e información histórica adicional pueden encontrarse en el sitio web de MacZFS y FAQ.

17 de septiembre de 2013 lanzamiento de OpenZFS incluye ZFS-OSX, que se convertirá en una nueva versión de MacZFS, como la distribución de Darwin.

Véase también

• APFS– para los sistemas operativos de Apple
• Btrfs-para Linux
• Comparación de sistemas de archivos
• ext4
• MARTILLO– establece un sistema de archivos con una característica similar para DragonFly BSD
• LFS-BSD registro estructurado sistema de archivos
• Lista de sistemas de archivos
• LVM– lógica Volume Manager (Linux), soporta copias instantáneas
• LZJB-algoritmo de compresión de datos utilizado en ZFS
• NILFS– un sistema de archivos Linux con sumas de comprobación (pero no de limpieza), apoyando también las instantáneas
• Ref– un sistema de archivos de Microsoft con las características de resiliencia incorporada
• Reiser4
• Almacenamiento abierto de Sun
• Sistema de archivos Veritas y Veritas Volume Manager– similar a ZFS
• Sistemas de archivos de control de versiones– lista de control de versiones de sistemas de archivos
• Escriba en cualquier estructura de ficheros– un sistema similar de archivo por NetApp

Bibliografía

• Watanabe, Scott (23 de noviembre de 2009). "Fundamentos de Solaris ZFS" (1ª ed.). Prentice Hall:: 256. ISBN 0-13-700010-3. Archivado de el original en 01 de octubre de 2012. 

Acoplamientos externos

• El proyecto de OpenZFS
• Comparación de SVM espejado y espejado de ZFS
• Distribución de ZFS Storage (NAS) de EON
• ZFS en Linux Homepage
• Integridad de datos end-to-end para sistemas de archivos: un estudio de caso ZFS
• ZFS – el sistema de archivos Zettabyte, archivado del original el 28 de febrero de 2013
• ¿ZFS y RAID-Z: el Über-FS?
• ZFS: La palabra pasada en sistemas de archivos, por Jeff Bonwick y Bill Moore
• Visualizar el registro de ZFS intent (ZIL), Abril de 2013, por Aaron Toponce

Otras Páginas

• Diverticulo de
• Datafication
• Iniciativa de INum (seccion llamada iNums mediante SIP URI)
• Nowe Gatne
• Spam con imagenes
• Estacion de Yulhyeon
• EmailTray
• Ida y vuelta a Marte