ZFS (sistema de archivos)

ZFS
Desarrollador	Oracle (originalmente Sun Microsystems). Equipo de desarrollo de OpenZFS como fork.
Nombre completo	Z File System
Género	Local file system
Licencia	CCDL
Sistemas operativos compatibles	Sun Solaris y derivados Linux (módulo de kernel nativo o vía FUSE) ​ FreeBSD y similares Mac OS X (Mountain Lion y posteriores) Windows (soporte de sólo lectura experimental a través de DOKAN)
Lanzamiento inicial	Noviembre de 2005
Última versión estable	28 (Oracle) 0.6.3 (OpenZFS)
Sitio web	https://java.net/projects/solaris-zfs
Introducción	Noviembre 2005 (OpenSolaris)
Identificador de la partición	83 (en Linux)
Estructuras
Contenido del directorio	Extensible Hash table
Límites
Máxima dimensión de archivo	16 exabytes
Máximo número de archivos	248
Tamaño máximo del volumen	16 exabytes
Características
Bifurcaciones	Sí (llamada Extended Attributes)
Atributos	POSIX
Permisos de acceso a archivos	POSIX
Compresión transparente	Sí
Cifrado transparente	No
Deduplicación de datos	Sí
Copy-on-write	Sí

ZFS es un sistema de archivos y volúmenes desarrollado por Sun Microsystems para su sistema operativo Solaris. El significado original era 'Zettabyte File System', pero ahora es un acrónimo recursivo.

El anuncio oficial de ZFS se produjo en septiembre de 2004. El código fuente del producto final se integró en la rama principal de desarrollo de Solaris el 31 de octubre de 2005 y fue lanzado el 16 de noviembre de 2005 como parte del build 27 de OpenSolaris.

ZFS fue diseñado e implementado por un equipo de Sun liderado por Jeff Bonwick.

ZFS destaca por su gran capacidad, integración de los conceptos anteriormente separados de sistema de ficheros y administrador de volúmenes en un solo producto, nueva estructura sobre el disco, sistemas de archivos ligeros y una administración de espacios de almacenamiento sencilla.

Capacidad

128 bits (2⁷ veces la capacidad de un sistema de ficheros de 64 bits).

Los límites de ZFS están diseñados para ser tan grandes que no se encuentren nunca en la práctica. Respecto a la capacidad del sistema, Jeff Bonwick, el arquitecto jefe de Sun para ZFS, dijo "Llenar un sistema de archivos de 128 bits excedería los límites cuánticos de almacenamiento de la Tierra. No puedes rellenarlo sin hervir los océanos".

Algunos límites teóricos de ZFS son:

• 2⁴⁸ — Número de snapshots en cualquier sistema de ficheros (2 × 10¹⁴)
• 2⁴⁸ — Número de ficheros en un sistema de ficheros (2 × 10¹⁴)
• 16 exabytes — Tamaño máximo de un sistema de ficheros.
• 16 exabytes — Tamaño máximo de un fichero.
• 16 exabytes — Tamaño máximo de cualquier atributo.
• 3 × 10²³ petabytes — Tamaño máximo de un zpool.
• 2⁵⁶ — Número de atributos de un fichero (realmente limitado a 2⁴⁸ que es el número de ficheros que puede contener un sistema de ficheros ZFS).
• 2⁵⁶ — Número de ficheros en un directorio (realmente limitado a 2⁴⁸ que es el número de ficheros que puede contener un sistema de ficheros ZFS).
• 2⁶⁴ — Número de dispositivos en cualquier zpool.
• 2⁶⁴ — Número de zpools en un sistema.
• 2⁶⁴ — Número de sistemas de ficheros en un zpool.

Como ejemplo de las capacidades expresadas por estos números, si un usuario crease 1000 ficheros por segundo, tardaría unos 9000 años en alcanzar el límite impuesto por el número de ficheros.

Auto reparación (Self-healing)

En pools de estructura mirror o raidz1 y raidz2 (equivalentes a raid 5 y raid 6 respectivamente pero sin el defecto de write-hole que sufren estos últimos), todos los datos son hasheados previamente a su escritura en el bloque lógico del pool (el algoritmo del hash se puede configurar por dataset). Una vez escritos los datos, el hash es comprobado para verificar la correcta inscripción de los mismos. Este hash es asociado a través de un sistema de metadatos al bloque lógico, de tal modo que cuando se accede a los datos del bloque lógico, se hace un chequeo de su integridad (a través de la comparación del hash guardado como metadato y el calculado con los datos del bloque). Si hay discordancia entre los datos, siendo sistemas con redundancia, procede a buscar en el bloque espejo (mirror) o a calcular los datos a través del sistema de paridad empleado (raidz1 y raidz2). Si los datos obtenidos con dicha fuente son correctos (equivalencia en los hash calculado y archivado) se procede a la corrección de los datos del bloque dañado, así como al envio de los datos solicitados a la aplicación. Esta característica permite la detección de fallos tanto en discos como en memorias, fuentes de alimentación, placas base, etc.

Modelo transaccional (Copy-on-write)

ZFS utiliza un modelo transaccional copy-on-write. Todos los punteros a bloques de un sistema de ficheros contienen un checksum de 256 bits sobre el bloque apuntado, que se comprueba al leer el bloque. Los bloques que contienen datos activos no se sobrescriben nunca; en su lugar, se reserva un nuevo bloque, y los datos modificados se escriben en él, y entonces cualquier bloque de metadatos que lo referencie es, de modo similar, reubicado y escrito. Para reducir la sobrecarga de este proceso, se agregan varias actualizaciones en grupos de transacciones, y se utiliza un log de intentos cuando se necesitan escrituras síncronas.

Instantáneas (Snapshots)

Como ZFS no sobrescribe datos, tomar una instantánea simplemente significa no liberar los bloques utilizados por versiones antiguas de los datos. La ventaja es que las instantáneas se toman rápidamente y también son eficientes desde el punto de vista del espacio, pues comparten los datos sin modificar con el sistema de ficheros.

Se pueden crear instantáneas modificables (llamadas clones), lo que resulta en dos sistemas de ficheros independientes que se crean compartiendo un conjunto común de bloques. A medida que se realizan cambios los bloques del sistema de ficheros divergen, pero los bloques comunes se mantendrán independientemente de cuantos clones existan.

Dynamic striping

ZFS permite expandir las bandas de un zpool con o sin redundancia, a medida que se agreguen dispositivos a un pool. En otras palabras, repartirá la carga de escritura de forma equitativa en todos los dispositivos, optimizando los procesos de lectura. Con las bandas de tamaño variable, mejora considerablemente los pools en Raid-Z y elimina de manera eficaz el problema de write-hole.

Tamaños de bloque variable

ZFS utiliza bloques de tamaño variable hasta 128K. El código disponible actualmente permite al administrador afinar el tamaño máximo de bloque utilizado, pues ciertas cargas no rinden bien con bloques grandes. También está contemplado un ajuste automático para adecuarse a las características de la carga de trabajo.

Si se activa la compresión se utilizan tamaños de bloque variable, si un bloque se puede comprimir para que quepa en un bloque de tamaño menor, se utiliza el bloque pequeño en el disco, de manera que no sólo se consume menos capacidad sino que se aumenta el throughput de entrada/salida (con el coste de aumentar la sobrecarga de la CPU).

Espacios de almacenamiento (Storage pools)

A diferencia de los sistemas de ficheros tradicionales que residen encima de un sólo dispositivo subyacente y por lo tanto requieren un gestor de volúmenes separado si se precisa un sistema de archivos mayor que el dispositivo, ZFS se apoya en espacios de almacenamiento virtuales (virtual storage pools). Los espacios se construyen a partir de uno o más dispositivos virtuales (vdevs), de los que cada uno es o bien un raw device, un mirror (RAID 1) de uno o más dispos todos los vdevs esa disponible para todos los sistemas de archivos del zpool.

Para limitar la cantidad de espacio que un sistema de ficheros puede ocupar, se pueden aplicar cuotas de disco, y garantizar que habrá espacio disponible para determinado sistema de ficheros. Se puede fijar una reserva de disco.

Creación de sistemas de ficheros ligeros

La creación de un nuevo sistema de ficheros en el interior de un espacio de almacenamiento ZFS es extremadamente rápida y fácil, mucho más parecida en tiempo y esfuerzo a crear un nuevo directorio en un sistema de archivos tradicional que al tiempo y esfuerzo necesario para crear un nuevo sistema de ficheros en cualquier otro SO tradicional. Estos sistemas de ficheros pueden tener cuotas reservadas y otras capacidades de administración útiles. Entre los usos posibles se encuentra la creación de un sistema de ficheros separado, no sólo un directorio, para cada usuario del sistema.

Capacidades adicionales

• Prioridad I/O explícita con deadline scheduling.
• Ordenación y agregación de I/O globalmente óptima.
• Multiple independent prefetch streams with automatic length and stride detection.
• Parallel, constant-time directory operations.

Para las aplicaciones ZFS es un sistema de ficheros estándar POSIX; no es necesario ningún cambio en las aplicaciones para guardar datos en ZFS.

Inconvenientes con datasets con compresión

Al permitir compresión, si un dataset está en el límite de su capacidad, el administrador de archivos o el shell podría mostrar discrepancias en el tamaño total de los archivos y el espacio libre. En este caso, la forma correcta de ver el espacio libre de un dataset es con zfs list dataset, el cual mostrará el espacio libre real del dataset. Esto ocurre en sistemas no soportados oficialmente por Oracle, como Linux.​

Enlaces externos

• ZFS Development Community
• Sitio Web de los desarrolladores de OpenZFS
• Detailed ZFS Documentation
• ZFS Kernel Source Code
• ZFS On-Disk Specification (PDF)
• Tour of ZFS Source Code: Incluye una visión detallada de la arquitectura y una presentación organizada de los ficheros fuente.
• 5-minute Demo of ZFS: Muestra algunas operaciones básicas en la línea de comandos en tiempo real, mientras un narrador explica las distintas características.
• 5-minute Demo of ZFS: Demostración de las características de auto reparación de ZFS después de un fallo catastrófico simulado.
• en:Comparison_of_file_systems: Comparativa de sistemas de ficheros
• en:Veritas_Volume_Manager: Principal competidor de ZFS