Capítulo 23. El Sistema de Archivos Z (ZFS)

Primero cree una partición GPT en un disco vacío. Luego añada una partición de tipo freebsd-zfs a partir de la cual se crea un grupo único y no redundante:

Para ver el nuevo grupo, revise la salida de df:

Esta salida muestra la creación y montaje del grupo example, y que ahora es accesible como un sistema de archivos. Cree archivos para que los usuarios naveguen:

Este grupo aún no utiliza ninguna característica o propiedad avanzada de ZFS. Para crear un conjunto de datos en este grupo con compresión activada:

El conjunto de datos example/compressed es ahora un sistema de archivos comprimido ZFS. Intente copiar algunos archivos grandes a /example/compressed.

Desactive la compresión con:

Para desmontar un sistema de archivos, use zfs umount y luego verifique con df:

Para volver a montar el sistema de archivos y hacerlo accesible nuevamente, use zfs mount y verifique con df:

Ejecutar mount muestra el grupo y los sistemas de archivos:

Use los conjuntos de datos ZFS como cualquier sistema de archivos después de su creación. Establezca otras características disponibles por conjunto de datos cuando sea necesario. El siguiente ejemplo crea un nuevo sistema de archivos llamado data. Asume que el sistema de archivos contiene archivos importantes y lo configura para almacenar dos copias de cada bloque de datos.

Use df para ver los datos y el uso de espacio:

Observe que todos los sistemas de archivos en el grupo tienen el mismo espacio disponible. Usar df en estos ejemplos muestra que los sistemas de archivos usan el espacio que necesitan y todos obtienen del mismo grupo. ZFS elimina conceptos como volúmenes y particiones, y permite que varios sistemas de archivos compartan el mismo grupo.

Para destruir los sistemas de archivos y luego el grupo que ya no se necesitan:

Los discos fallan. Una forma de evitar la pérdida de datos por fallos de disco es utilizar RAID. ZFS admite esta característica en su diseño de pools. Los pools RAID-Z requieren tres o más discos pero proporcionan más espacio utilizable que los pools en espejo.

Este ejemplo crea un pool RAID-Z. Primero se crean las particiones GPT en cada disco, luego se especifican estas particiones GPT para añadirlas al pool usando la palabra clave raidz:

El ejemplo anterior creó el zpool storage. Este ejemplo crea un nuevo sistema de archivos llamado home en ese pool:

Habilitar compresión y almacenar una copia adicional de directorios y archivos:

Para que este sea el nuevo directorio home de los usuarios, copie los datos de usuario a este directorio y cree los enlaces simbólicos apropiados:

Los datos de usuario ahora se almacenan en el recién creado /storage/home. Pruebe añadiendo un nuevo usuario e iniciando sesión como ese usuario.

Crear una instantánea del sistema de archivos para revertir más tarde:

ZFS crea instantáneas de un dataset, no de un directorio o archivo individual.

El carácter @ es un delimitador entre el nombre del sistema de archivos o volumen y el nombre de la instantánea. Antes de eliminar un directorio importante, haga una copia de seguridad del sistema de archivos, luego revierta a una instantánea anterior en la que el directorio aún exista:

Para listar todas las instantáneas disponibles, ejecute ls en el directorio .zfs/snapshot del sistema de archivos. Por ejemplo, para ver la instantánea tomada:

Escriba un script para tomar instantáneas regulares de los datos de usuario. Con el tiempo, las instantáneas pueden usar mucho espacio en disco. Elimine la instantánea anterior usando el comando:

Después de las pruebas, haga que /storage/home sea el verdadero /home con este comando:

Ejecute df y mount para confirmar que el sistema ahora trata el sistema de archivos como el verdadero /home:

Esto completa la configuración RAID-Z. Añada actualizaciones de estado diarias sobre los sistemas de archivos creados a las ejecuciones nocturnas de periodic(8) añadiendo esta línea a /etc/periodic.conf:

periodic(8) también puede ejecutar scrubs programados del pool; vea Scrubbing a Pool.

Todo RAID de software tiene un método para monitorizar su estado. Visualice el estado de los dispositivos RAID-Z utilizando:

Si todos los pools están Online y todo es normal, el mensaje mostrará:

Si hay un problema, quizás un disco esté en estado Offline, el estado del pool se verá así:

"OFFLINE" muestra que el administrador puso ada1p1 fuera de línea usando:

Apague el equipo ahora y reemplace ada1p1. Recreé la partición GPT de tipo freebsd-zfs en el nuevo disco. Encienda el equipo y devuelva ada1p1 al pool:

A continuación, compruebe el estado de nuevo, esta vez sin -x para mostrar todos los pools:

En este ejemplo, todo es normal.

ZFS utiliza sumas de comprobación (checksums) para verificar la integridad de los datos almacenados. La creación de sistemas de archivos las habilita automáticamente.

Verificar las sumas de comprobación de los datos (llamado scrubbing o limpieza) garantiza la integridad del pool storage con:

La duración de una limpieza depende de la cantidad de datos almacenados. Cantidades mayores de datos tardarán proporcionalmente más en verificarse. Dado que la limpieza es intensiva en E/S, ZFS permite que se ejecute una única limpieza en cada pool a la vez. Una vez completada la limpieza, visualice el estado con zpool status:

Mostrar la fecha de finalización de la última limpieza ayuda a decidir cuándo iniciar otra. Las limpiezas rutinarias ayudan a proteger los datos de la corrupción silenciosa y garantizan la integridad del pool.

Consulte zfs(8) y zpool(8) para conocer otras opciones de ZFS.

La decisión más importante al crear un pool de almacenamiento ZFS es elegir qué tipos de vdevs agruparán los discos físicos. Consulte la lista de tipos de vdev para obtener detalles sobre las opciones posibles. Los tipos de vdev determinan las características de redundancia, capacidad y rendimiento de un pool. El diseño de un pool no está fijo para siempre en el momento de la creación. Los espejos permiten agregar nuevos discos a la vdev, y las bandas se actualizan a espejos adjuntando un nuevo disco a la vdev. Las vdevs RAID-Z crecen un disco a la vez con expansión de RAID-Z, lo que requiere OpenZFS 2.3 o posterior, disponible por primera vez en FreeBSD 15.0. Agregar nuevas vdevs expande un pool en cualquier momento, y eliminar vdevs de nivel superior es posible dentro de ciertos límites. Reconfigurar un pool en funcionamiento requiere tiempo y ancho de banda de E/S, por lo que elegir tipos de vdevs adecuados desde el principio sigue siendo importante.

Cree un pool de espejo simple en discos que contengan particiones GPT de tipo freebsd-zfs:

Para crear más de una vdev con un solo comando, especifique grupos de discos separados por la palabra clave del tipo de vdev, mirror en este ejemplo:

Los pools también pueden usar particiones en lugar de discos completos. Poner ZFS en una partición separada permite que el mismo disco tenga otras particiones para otros propósitos. En particular, permite agregar particiones con código de arranque y sistemas de archivos necesarios para el booteo. Esto permite bootear desde discos que también son miembros de un pool. ZFS no añade penalización de rendimiento en FreeBSD al usar una partición en lugar de un disco completo. Usar particiones también permite al administrador sub-dimensionar los discos, usando menos de la capacidad total. Si un disco de reemplazo futuro del mismo tamaño nominal que el original tiene en realidad una capacidad ligeramente menor, la partición más pequeña aún encajará, utilizando el disco de reemplazo.

Cree un pool RAID-Z2 usando particiones:

ZFS alinea y dimensiona sus escrituras más pequeñas para cada vdev en función del valor ashift de la vdev, el logaritmo en base 2 del tamaño de sector. OpenZFS detecta el tamaño de sector que los discos reportan al crear una vdev y elige ashift en consecuencia. Algunas unidades reportan sectores de 512 bytes por compatibilidad mientras usan sectores de 4096 bytes internamente. Cree pools en dichas unidades con un -o ashift=12 explícito para forzar una alineación de 4096 bytes:

Establecer la variable sysctl(8) vfs.zfs.vdev.min_auto_ashift en 12 da el mismo resultado para la creación del pool y para operaciones posteriores de zpool add y zpool attach. ashift es una propiedad de cada vdev, no del pool en su conjunto. Se fija al crear la vdev y no puede cambiar posteriormente, así que verifíquelo antes de comprometer datos a un pool.

Destruya un pool que ya no necesite para reutilizar los discos. Destruir un pool requiere desmontar primero los sistemas de archivos en ese pool. Si cualquier dataset está en uso, la operación de desmontaje falla sin destruir el pool. Fuerce la destrucción del pool con -f. Esto puede causar un comportamiento indefinido en aplicaciones que tenían archivos abiertos en esos datasets.

Al igual que los datasets, los pools tienen propiedades que reportan estado y controlan el comportamiento. Muestre todas las propiedades de un pool con zpool get all mypool, o nombre propiedades específicas:

Cambie una propiedad editable con zpool set:

Propiedades como size, capacity, fragmentation y health son valores de estado de solo lectura. Otras cambian cómo se comporta el pool; este capítulo utiliza autoexpand para hacer crecer un pool automáticamente (Hacer Crecer un Pool), autoreplace con discos de repuesto en caliente (Discos de Repuesto en Caliente y Reemplazo Automático con zfsd), autotrim en pools SSD (TRIM e Inicialización) y compatibility para pools portables (Actualizar un Pool de Almacenamiento). Establezca propiedades al crear el pool pasando -o a zpool create, como se mostró con ashift anteriormente. zpoolprops(7) describe cada propiedad del pool.

Existen dos formas de agregar discos a un pool: adjuntando un disco a un vdev existente con zpool attach, o añadiendo vdevs al pool con zpool add. Algunos tipos de vdev permiten agregar discos al vdev después de su creación. Los vdevs RAID-Z solo aceptan discos nuevos mediante expansión de RAID-Z.

Un pool creado con un solo disco carece de redundancia. Puede detectar corrupción pero no puede repararla, porque no hay otra copia de los datos. La propiedad copies puede ser capaz de recuperarse de un fallo pequeño como un sector defectuoso, pero no proporciona el mismo nivel de protección que el mirroring o RAID-Z. Comenzando con un pool que consiste en un vdev de disco único, use zpool attach para agregar un nuevo disco al vdev, creando un espejo. También use zpool attach para agregar discos nuevos a un grupo de espejo, aumentando la redundancia y el rendimiento de lectura. Al particionar los discos utilizados para el pool, replique el diseño del primer disco en el segundo. Use gpart backup y gpart restore para facilitar este proceso.

Actualice el vdev de disco único (stripe) ada0p3 a un espejo adjuntando ada1p3:

Cuando agregar discos al vdev existente no es una opción, un método alternativo es añadir otro vdev al pool. Añadir vdevs proporciona un mayor rendimiento distribuyendo las escrituras a través de los vdevs. Cada vdev proporciona su propia redundancia. Mezclar tipos de vdev como mirror y RAID-Z es posible pero se desaconseja. Agregar un vdev no redundante a un pool que contiene vdevs de espejo o RAID-Z pone en riesgo los datos de todo el pool. Distribuir las escrituras significa que un fallo del disco no redundante resultará en la pérdida de una fracción de cada bloque escrito en el pool.

ZFS distribuye los datos (stripes) a través de cada uno de los vdevs. Por ejemplo, con dos vdevs de espejo, esto es efectivamente un RAID 10 que distribuye las escrituras a través de dos conjuntos de espejos. ZFS asigna el espacio para que cada vdev alcance el 100% de llenado al mismo tiempo. Tener vdevs con diferentes cantidades de espacio libre reducirá el rendimiento, ya que más escrituras de datos irán al vdev menos lleno.

Al adjuntar dispositivos nuevos a un pool de arranque, recuerde actualizar el código de arranque.

Adjunte un segundo grupo de espejo (ada2p3 y ada3p3) al espejo existente:

zpool add también adjunta dispositivos de registro (log) y caché (cache) dedicados a un pool existente. Un vdev log almacena el registro de intenciones de ZFS (ZFS intent log) en almacenamiento separado de baja latencia, acelerando las escrituras síncronas como las emitidas por bases de datos y NFS. Se recomienda dispositivos de registro en espejo, porque perder un dispositivo de registro no reflejado junto con un bloqueo del sistema le cuesta al pool los últimos segundos de escrituras síncronas; consulte Escrituras Síncronas, el ZIL y el SLOG para obtener orientación sobre dimensionamiento y ajuste. Un vdev cache extiende el ARC con un segundo nivel de caché de lectura en almacenamiento rápido. Los dispositivos de caché no necesitan redundancia, ya que ZFS lee cualquier bloque que no pueda leer de la caché desde los discos originales del pool. El contenido de la caché, el L2ARC, sobrevive a los reinicios por defecto.

Agregue un vdev de registro en espejo y un dispositivo de caché NVMe a un pool existente:

zpool detach elimina discos individuales de un vdev de espejo cuando permanece suficiente redundancia. Si queda un solo disco en un grupo de espejo, ese grupo deja de ser un espejo y se convierte en una distribución (stripe), arriesgando todo el pool si ese disco restante falla.

Elimine un disco de un grupo de espejo de tres vías:

zpool remove elimina vdevs de nivel superior completos de un pool. ZFS evacúa el vdev copiando todos sus datos asignados a los otros vdevs en el pool, y luego desacopla los discos. La eliminación funciona para dispositivos de repuesto en caliente (hot spares), caché, registro (log), especiales (special) y de deduplicación (dedup), y para vdevs de datos que son discos únicos o espejos. Los vdevs de datos no son removibles de pools que contienen un vdev RAID-Z de nivel superior, y todos los vdevs de nivel superior en el pool deben usar el mismo ashift. La evacuación se ejecuta en segundo plano y el pool permanece en línea durante todo el proceso; supervise el progreso con zpool status. Después de que se complete la eliminación, ZFS mantiene una tabla en memoria que mapea los bloques del vdev eliminado a sus nuevas ubicaciones. La tabla es pequeña pero permanente; zpool remove -n estima su uso de memoria antes de iniciar una eliminación.

Elimine uno de los dos vdevs de espejo de un pool:

La entrada indirect-1 es un marcador de posición para los bloques reasignados del vdev eliminado y no contiene discos. Cancele una eliminación en curso con zpool remove -s.

La expansión de RAID-Z aumenta un vdev RAID-Z existente de un disco a la vez, sin cambiar su nivel de paridad.

Para expandir un vdev RAID-Z, ejecute zpool attach con el nombre del vdev RAID-Z como se muestra en zpool status y el nuevo disco:

La expansión redistribuye los datos existentes a través del conjunto ampliado de discos en segundo plano mientras el pool permanece en línea y en uso. Añada -w para que zpool attach espere hasta que la expansión se complete. zpool status informa del progreso en la línea expand::

Cuando la expansión finaliza, la capacidad del nuevo disco queda disponible:

Los bloques escritos antes de la expansión mantienen su antigua proporción de datos a paridad y continúan ocupando espacio en consecuencia. La ganancia de capacidad completa del nuevo disco se aplica por tanto a los datos escritos después de la expansión, mientras que los datos antiguos solo se benefician cuando se reescriben, por ejemplo con zfs rewrite. Repita el procedimiento para aumentar un vdev en varios discos, conectando uno cada vez.

dRAID es una variante de RAID-Z que distribuye la capacidad de repuesto en caliente a través de todos los discos del vdev. Un vdev dRAID se construye a partir de grupos RAID-Z internos más repuestos distribuidos opcionales, todos distribuidos uniformemente sobre cada disco. Cuando un disco falla, ZFS reconstruye en el repuesto distribuido leyendo y escribiendo en todos los discos restantes en paralelo, completando en una fracción del tiempo que lleva una resilverización en un solo disco de repuesto. Reemplazar el disco fallado luego lo reconstruye desde el repuesto distribuido, restaurando la protección completa. dRAID está dirigido a pools con muchos discos, donde los tiempos de reconstrucción de RAID-Z se vuelven peligrosamente largos.

El tipo de vdev especifica el diseño completo, según zpoolconcepts(7):

parity es el nivel de paridad de los grupos internos, de 1 a 3, por defecto 1. data es el número de dispositivos de datos por grupo de redundancia, por defecto 8. children es el número total de discos, sirviendo como comprobación cruzada al enumerar muchos dispositivos. spares es el número de repuestos en caliente distribuidos, por defecto 0.

Cree un pool a partir de un vdev dRAID de 24 discos con doble paridad, 8 discos de datos por grupo de redundancia y 2 repuestos distribuidos:

Los repuestos distribuidos aparecen bajo spares en zpool status, con nombres como draid2-0-0 para el primer repuesto del primer vdev.

dRAID intercambia eficiencia de espacio por velocidad de reconstrucción. A diferencia de RAID-Z, dRAID utiliza un ancho de banda fijo, rellenando las escrituras más pequeñas con ceros. Con el valor predeterminado de 8 discos de datos y sectores de 4 KB, la asignación mínima es de 32 KB, lo que reduce la capacidad utilizable y la efectividad de la compresión para conjuntos de datos dominados por bloques pequeños. La capacidad de los repuestos distribuidos también se compromete por adelantado, independientemente de que un disco falle o no. Emparejar un pool dRAID con un vdev especial mantiene los metadatos y bloques pequeños fuera de las bandas anchas y recupera gran parte de la eficiencia perdida. Para pools con un puñado de discos, RAID-Z sigue siendo la mejor opción.

Las clases de asignación especiales dedican vdevs a tipos específicos de datos del pool. Un vdev especial almacena metadatos del pool como bloques indirectos y dnodes, y opcionalmente los bloques de datos de archivos pequeños. Un vdev dedup almacena las tablas de deduplicación. Colocar estos metadatos en dispositivos rápidos como espejos NVMe acelera operaciones intensivas en metadatos como el recorrido de directorios, zfs list y búsquedas de deduplicación en pools de discos por lo demás más lentos.

Añada un vdev especial en espejo a un pool existente:

Las nuevas asignaciones de metadatos irán entonces al vdev especial; los metadatos existentes permanecen donde están hasta que se reescriban.

Establecer la propiedad de conjunto de datos special_small_blocks hace que el vdev especial también almacene bloques de datos hasta el tamaño dado:

Los valores válidos son cero, lo que desactiva el almacenamiento de bloques de datos en la clase especial, o una potencia de dos desde 512 bytes hasta 1 MB en FreeBSD 14.x; FreeBSD 15.0 acepta valores hasta el tamaño máximo de bloque de 16 MB. Establecer la propiedad al recordsize del conjunto de datos envía todos los bloques de datos de ese conjunto a la clase especial. Cuando un vdev especial se llena, las nuevas asignaciones vuelven a la clase normal en lugar de fallar.

Eliminar un vdev especial o dedup con zpool remove es posible, sujeto a las restricciones descritas en Añadir y Eliminar Dispositivos. En la práctica, el requisito de ashift coincidente a menudo impide la eliminación cuando el vdev especial utiliza dispositivos con un tamaño de sector diferente al de los vdevs de datos.

El estado del pool es importante. Si una unidad se desconecta o ZFS detecta un error de lectura, escritura o de suma de comprobación, el contador de errores correspondiente aumenta. La salida de status muestra la configuración y el estado de cada dispositivo en el pool y el estado del pool completo. También se muestran las acciones a tomar y los detalles sobre el último scrub.

Las opciones ajustan la salida a la tarea en cuestión:

Consulte zpool-status(8) para obtener la lista completa de opciones.

Al detectar un error, ZFS incrementa los contadores de errores de lectura, escritura o de suma de comprobación. Borre el mensaje de error y reinicie los contadores con zpool clear mypool. Borrar el estado de error puede ser importante para scripts automatizados que alertan al administrador cuando el pool encuentra un error. Sin borrar los errores antiguos, los scripts pueden fallar al reportar errores posteriores.

Puede ser deseable reemplazar un disco por otro diferente. Al reemplazar un disco funcional, el proceso mantiene el disco antiguo en línea durante la sustitución. El pool nunca entra en un estado degradado, reduciendo el riesgo de pérdida de datos. Ejecutar zpool replace copia los datos del disco antiguo al nuevo. Después de que la operación se complete, ZFS desconecta el disco antiguo del vdev. Si el nuevo disco es más grande que el antiguo, puede ser posible expandir el zpool, utilizando el nuevo espacio. Véase Expansión de un Pool.

Sustituya un dispositivo funcional en el pool:

En vdevs en espejo, añadir -s a zpool replace o zpool attach realiza un resilver secuencial en lugar de un resilver de curación. Un resilver secuencial copia los datos en orden de disco sin verificar la suma de comprobación de cada bloque, restaurando la redundancia mucho más rápido. Dado que la copia omite la verificación de la suma de comprobación, ZFS inicia un scrub del pool automáticamente después de que el resilver secuencial se complete. El resilver secuencial funciona en vdevs en espejo y dRAID, no en RAID-Z. Reinicie un resilver en curso desde el principio con zpool resilver mypool.

Cuando un disco de un pool falla, el vdev al que pertenece el disco entra en estado degradado. Los datos siguen estando disponibles, pero con un rendimiento reducido porque ZFS calcula los datos que faltan a partir de la redundancia disponible. Para restaurar el vdev a un estado completamente funcional, reemplace el dispositivo físico fallido. Se le indica entonces a ZFS que inicie la operación resilverización. ZFS recalcula los datos del dispositivo fallido a partir de la redundancia disponible y los escribe en el dispositivo de reemplazo. Tras su finalización, el vdev vuelve al estado en línea.

Si el vdev no tiene ninguna redundancia, o si los dispositivos han fallado y no hay suficiente redundancia para compensarlo, el pool entra en estado en fallo. A menos que se puedan reconectar suficientes dispositivos, el pool se vuelve inoperativo, requiriendo una restauración de datos a partir de copias de seguridad.

Al reemplazar un disco fallido, el nombre del disco fallido cambia al GUID del nuevo disco. No se requiere un nuevo parámetro de nombre de dispositivo para zpool replace si el dispositivo de reemplazo tiene el mismo nombre de dispositivo.

Reemplace un disco fallido usando zpool replace:

Los pools con vdevs redundantes pueden registrar discos de reserva (hot spare) que permanecen en espera para reemplazar un dispositivo fallido. Un disco de reserva debe ser al menos tan grande como el dispositivo que reemplaza. Especifique discos de reserva en el momento de creación del pool listándolos después de la palabra clave spare, como en zpool create mypool mirror ada0p3 ada1p3 spare ada3p3, o añádalos a un pool existente con zpool add:

Un disco de reserva permanece inactivo, mostrado como AVAIL, hasta que un dispositivo falla. Active un disco de reserva manualmente con zpool replace, nombrando el dispositivo fallido y el de reserva:

El reemplazo por el disco de reserva es temporal por diseño, y el pool permanece en este estado hasta que un administrador lo resuelva. Después de reemplazar físicamente el disco fallido y resilverizar el nuevo dispositivo con zpool replace, devuelva el disco de reserva al estado de espera con zpool detach mypool ada3p3. Para promover el disco de reserva a miembro permanente del vdev en su lugar, desvincule el dispositivo fallido con zpool detach mypool ada1p3.

La propiedad de pool autoreplace, desactivada por defecto, controla qué sucede cuando un nuevo disco aparece en la misma ubicación física que un dispositivo que previamente pertenecía al pool. Con autoreplace establecido en on, ZFS reemplaza automáticamente el dispositivo antiguo por el nuevo disco, sin requerir un comando zpool replace:

En FreeBSD, las reacciones automáticas a fallos, incluyendo el respeto a autoreplace, son realizadas por zfsd(8), el demonio de gestión de fallos de ZFS en el sistema base. El demonio no está habilitado por defecto. Habilítelo e inícielo con:

zfsd(8) escucha eventos del pool y:

Inspeccione el flujo de eventos que impulsa estas decisiones con zpool events. Añadir -v muestra la carga útil completa de cada evento, y -f mantiene el comando en ejecución, imprimiendo nuevos eventos a medida que llegan. ZFS también entrega estos eventos a devd(8). Las reglas en /etc/devd/zfs.conf los registran en el registro del sistema y sirven como plantilla para acciones personalizadas, como enviar correo cuando un pool se degrada.

Realice limpiezas de los pools de forma rutinaria, idealmente al menos una vez al mes. La operación scrub es intensiva en disco y reducirá el rendimiento mientras se ejecuta. Evite los períodos de alta demanda al programar scrub, o reduzca su impacto con los ajustes del planificador de E/S descritos en Ajustes Avanzados.

Pause una limpieza en ejecución con zpool scrub -p mypool cuando interfiera con otro trabajo; ejecutar zpool scrub mypool nuevamente la reanuda desde donde se detuvo. Para cancelar una operación de limpieza en su lugar, ejecute zpool scrub -s mypool. zpool scrub -w mypool espera hasta que la limpieza se complete antes de regresar, lo que es útil en scripts. Después de que una limpieza reporte errores, zpool scrub -e mypool realiza una limpieza de errores que solo vuelve a verificar los bloques con errores conocidos, finalizando mucho más rápido que una limpieza completa. La limpieza de errores requiere OpenZFS 2.2, incluido por primera vez en FreeBSD 14.0.

periodic(8) puede ejecutar limpiezas automáticamente. Para limpiar cada pool cuya última limpieza tenga más de 35 días, agregue esta línea a /etc/periodic.conf:

Establezca daily_scrub_zfs_default_threshold="días" para cambiar el número de días entre limpiezas. periodic.conf(5) también describe umbrales por pool. Establecer daily_status_zfs_enable="YES" agrega una verificación de salud del pool al reporte diario de periodic(8).

Las sumas de comprobación almacenadas con los bloques de datos permiten que el sistema de archivos se autorepare. Esta característica reparará automáticamente los datos cuya suma de comprobación no coincida con la registrada en otro dispositivo que forme parte del pool de almacenamiento. Por ejemplo, una configuración en espejo con dos discos donde una unidad está empezando a funcionar mal y ya no puede almacenar los datos correctamente. Esto es peor cuando los datos no se accedieron durante mucho tiempo, como con el almacenamiento de archivo a largo plazo. Los sistemas de archivos tradicionales necesitan ejecutar comandos que verifiquen y reparen los datos como fsck(8). Estos comandos toman tiempo y, en casos severos, un administrador debe decidir qué operación de reparación realizar. Cuando ZFS detecta un bloque de datos con una suma de comprobación que no coincide, intenta leer los datos del disco espejo. Si ese disco puede proporcionar los datos correctos, ZFS se los dará a la aplicación y corregirá los datos en el disco con la suma de comprobación incorrecta. Esto ocurre sin ninguna interacción de un administrador del sistema durante la operación normal del pool.

El siguiente ejemplo muestra este comportamiento de autoreparación creando un pool en espejo de las particiones /dev/ada0p1 y /dev/ada1p1.

Copie algunos datos importantes al pool para protegerlos de errores de datos utilizando la función de autoreparación y cree una suma de comprobación del pool para una comparación posterior.

Simule corrupción de datos escribiendo datos aleatorios al principio de uno de los discos en el espejo. Para evitar que ZFS repare los datos cuando los detecte, exporte el pool antes de la corrupción e impórtelo de nuevo después.

El estado del pool muestra que un dispositivo ha experimentado un error. Tenga en cuenta que las aplicaciones que leen datos del pool no recibieron ningún dato incorrecto. ZFS proporcionó datos del dispositivo ada0p1 con las sumas de comprobación correctas. Para encontrar el dispositivo con la suma de comprobación incorrecta, busque aquel cuya columna CKSUM contenga un valor distinto de cero.

ZFS detectó el error y lo manejó utilizando la redundancia presente en el dispositivo espejo no afectado ada0p1. Una comparación de la suma de comprobación con la original revelará si el pool vuelve a ser consistente.

Genere sumas de comprobación antes y después de la manipulación intencional mientras los datos del pool aún coinciden. Esto muestra cómo ZFS es capaz de detectar y corregir cualquier error automáticamente cuando las sumas de comprobación difieren. Tenga en cuenta que esto es posible con suficiente redundancia presente en el pool. Un pool que consta de un solo dispositivo no tiene capacidades de autoreparación. Esa es también la razón por la que las sumas de comprobación son tan importantes en ZFS; no las desactive por ningún motivo. ZFS no requiere fsck(8) o un programa similar de verificación de consistencia del sistema de archivos para detectar y corregir esto, y mantiene el pool disponible mientras hay un problema. Ahora se requiere una operación de limpieza para sobrescribir los datos corruptos en ada1p1.

La operación de limpieza lee datos de ada0p1 y reescribe cualquier dato con una suma de comprobación incorrecta en ada1p1, mostrado por la salida (repairing) de zpool status. Después de que la operación se completa, el estado del pool cambia a:

Después de que la operación de limpieza se completa con todos los datos sincronizados desde ada0p1 a ada1p1, borre los mensajes de error del estado del pool ejecutando zpool clear.

El pool ahora está de vuelta a un estado completamente funcional, con todos los contadores de errores ahora en cero.

Las unidades de estado sólido y el almacenamiento con aprovisionamiento fino funcionan mejor cuando ZFS les indica qué bloques ya no están en uso. zpool trim pasa esa información a cada dispositivo del grupo que admita los comandos TRIM o UNMAP:

Recorte un único dispositivo nombrándolo después del grupo, como en zpool trim mypool nda0p3. zpool trim -w espera hasta que el recorte se complete, -c cancela un recorte en ejecución y -s lo suspende; ejecutar zpool trim nuevamente reanuda un recorte suspendido. En dispositivos que lo admitan, zpool trim --secure solicita un TRIM seguro, donde el dispositivo garantiza el borrado de los datos almacenados en los bloques recortados.

zpool status -t muestra el progreso del recorte para cada dispositivo:

Establecer la propiedad de grupo autotrim en on hace que ZFS emita pequeños comandos TRIM de forma continua a medida que el grupo libera espacio:

El recorte automático omite pequeñas regiones liberadas y pone una carga extra constante en los dispositivos. Para la mayoría de los sistemas, dejar autotrim desactivado y ejecutar un zpool trim completo de forma programada da mejores resultados. En FreeBSD 14.1 y posteriores, periodic(8) ejecuta dicho recorte diariamente cuando /etc/periodic.conf contiene daily_trim_zfs_enable="YES".

zpool initialize es la contraparte del recorte: escribe un patrón en todo el espacio no asignado de los dispositivos especificados, o en cada dispositivo elegible del grupo cuando no se dan nombres de dispositivo. Esto fuerza al almacenamiento subyacente a asignar el espacio por adelantado, evitando la latencia de la primera escritura en discos virtuales con aprovisionamiento fino, y ejercita nuevos dispositivos antes de confiarles datos.

Al igual que con el recorte, -c cancela una inicialización, -s la suspende y -w espera a que finalice; -u elimina el estado de inicialización de los dispositivos. Consulte zpool-trim(8) y zpool-initialize(8) para obtener detalles.

zpool checkpoint guarda el estado de todo el grupo, incluyendo cada conjunto de datos y la configuración del grupo, de modo que una posterior reversión devuelva el grupo al estado exacto que tenía al crear el punto de control. Cree un punto de control antes de operaciones administrativas arriesgadas como actualizar el sistema operativo, habilitar nuevas características del grupo o reorganizar conjuntos de datos:

Un grupo contiene como máximo un punto de control a la vez. La columna CKPOINT de zpool list muestra cuánto espacio consume el punto de control a medida que el grupo diverge del estado guardado:

Para revertir, exporte el grupo e impórtelo de nuevo con --rewind-to-checkpoint:

La reversión descarta todo cambio realizado en el grupo después de crear el punto de control, incluyendo instantáneas más recientes y cambios de propiedades. Descarte un punto de control que ya no sea necesario para liberar el espacio que ocupa; -w espera hasta que el descarte se complete:

Mientras exista un punto de control, ZFS rechaza operaciones que cambian la estructura del grupo: zpool remove, zpool attach, zpool detach, zpool split y zpool reguid. El espacio liberado después de crear el punto de control no se reclama hasta que este se descarta, por lo que un punto de control de larga duración en un grupo activo puede llenarlo.

Consulte zpool-checkpoint(8) para obtener detalles.

El dispositivo más pequeño en cada vdev limita el tamaño utilizable de un grupo redundante. Reemplace el dispositivo más pequeño con un dispositivo más grande. Después de completar una operación de reemplazo o resincronización, el grupo puede crecer para usar la capacidad del nuevo dispositivo. Por ejemplo, considere un espejo de una unidad de 1 TB y una de 2 TB. El espacio utilizable es de 1 TB. Al reemplazar la unidad de 1 TB con otra de 2 TB, el proceso de resincronización copia los datos existentes en la nueva unidad. Como ambos dispositivos tienen ahora capacidad de 2 TB, el espacio disponible del espejo crece a 2 TB.

El grupo no utiliza la nueva capacidad automáticamente por defecto. Establezca la propiedad de grupo autoexpand en on antes de reemplazar los dispositivos y el grupo crecerá tan pronto como el último dispositivo más pequeño abandone el vdev:

De lo contrario, inicie la expansión usando zpool online -e en cada dispositivo. Después de expandir todos los dispositivos, el espacio extra estará disponible para el grupo.

Para expandir un vdev RAID-Z añadiendo un disco en lugar de reemplazar los existentes, consulte Expansión de RAID-Z.

Exporte los pools antes de moverlos a otro sistema. ZFS desmonta todos los conjuntos de datos, marcando cada dispositivo como exportado pero aún bloqueado para evitar su uso por otros discos. Esto permite que los pools se importen en otras máquinas, otros sistemas operativos que admiten ZFS e incluso diferentes arquitecturas de hardware (con algunas salvedades, véase zpool(8)). Cuando un conjunto de datos tiene archivos abiertos, utilice zpool export -f para forzar la exportación del pool. Utilice esto con precaución. Los conjuntos de datos se desmontan forzosamente, lo que podría resultar en un comportamiento inesperado por parte de las aplicaciones que tenían archivos abiertos en esos conjuntos de datos.

Exporte un pool que no esté en uso:

Importar un pool monta automáticamente los conjuntos de datos. Si este comportamiento no es deseado, utilice zpool import -N para prevenirlo. zpool import -o establece propiedades temporales para esta importación específica. zpool import -o altroot= permite importar un pool con un punto de montaje base en lugar de la raíz del sistema de archivos. Si el pool se utilizó por última vez en un sistema diferente y no se exportó correctamente, fuerce la importación usando zpool import -f. zpool import -a importa todos los pools que no parecen estar en uso por otro sistema.

zpool-import(8) también proporciona opciones para recuperar pools dañados. zpool import -F intenta retroceder el pool a un grupo de transacciones anterior cuando los más recientes están dañados, descartando los últimos segundos de escrituras. zpool import -m permite importar un pool cuyo dispositivo de registro dedicado falta. zpool import -o readonly=on importa el pool como solo lectura, impidiendo todas las escrituras, lo que es útil para análisis forense o cuando se rescatan datos de un pool que está fallando. zpool import -R /mnt combina altroot=/mnt con cachefile=none, evitando que una importación de rescate perturbe las rutas de montaje y la caché de pool del sistema en ejecución.

Liste todos los pools disponibles para importar:

Importe el pool con un directorio raíz alternativo:

Al arrancar, los scripts de inicio de ZFS habilitados por zfs_enable="YES" en /etc/rc.conf importan cada pool registrado en /etc/zfs/zpool.cache. Importar un pool lo añade a ese archivo de caché automáticamente; la propiedad de pool cachefile controla este comportamiento. Los pools importados con cachefile=none no regresan automáticamente después de un reinicio.

Después de actualizar FreeBSD, o si importa un pool desde un sistema que utiliza una versión anterior, actualice manualmente el pool para hacer disponibles nuevas características en disco. Considere si el pool podría necesitar importarse en un sistema anterior antes de actualizar. La actualización es un proceso unidireccional. Es posible actualizar pools antiguos, pero no es posible revertir pools con características más nuevas.

Los pools ya no llevan un único número de versión. En su lugar, cada cambio de formato en disco es una bandera de característica individual, descrita en zpool-features(7). Una característica se habilita cuando el pool permite su uso y se vuelve activa una vez que el pool almacena datos que dependen de ella. Una característica habilitada pero inactiva no afecta la compatibilidad. Una vez que una característica está activa, el software sin soporte para ella ya no puede importar el pool, aunque los pools cuyas características activas son todas "compatibles de solo lectura" aún permiten importaciones de solo lectura.

zpool status informa cuando características admitidas no están habilitadas en un pool:

Ejecutar zpool upgrade sin argumentos lista cada pool con características deshabilitadas:

Utilice zpool upgrade -v para listar cada característica que el sistema en ejecución admite, junto con los números de versión heredados. Habilite todas las características admitidas en un pool:

Los pools que deben permanecer importables en sistemas que ejecutan software ZFS más antiguo pueden restringir qué características zpool create y zpool upgrade habilitan mediante la propiedad de pool compatibility:

Establecer la propiedad en un pool existente con zpool set también funciona. Cada conjunto de características nombrado corresponde a un archivo en /usr/share/zfs/compatibility.d, y el valor predeterminado off permite todas las características. Establecer la propiedad no deshabilita características que ya están habilitadas.

ZFS registra los comandos que cambian el pool, incluyendo la creación de conjuntos de datos, el cambio de propiedades o el reemplazo de un disco. Revisar el historial sobre la creación de un pool es útil, al igual que comprobar qué usuario realizó una acción específica y cuándo. El historial no se guarda en un archivo de registro, sino que es parte del pool mismo. El comando para revisar este historial se llama acertadamente zpool history:

La salida muestra comandos zpool y zfs que alteran el pool de alguna manera junto con una marca de tiempo. Comandos como zfs list no se incluyen. Cuando no se especifica un nombre de pool, ZFS muestra el historial de todos los pools.

zpool history puede mostrar aún más información al proporcionar las opciones -i o -l. -i muestra eventos iniciados por el usuario así como eventos internos registrados por ZFS.

Muestre más detalles añadiendo -l. Muestra los registros de historial en un formato largo, incluyendo información como el nombre del usuario que emitió el comando y el hostname en el que ocurrió el cambio.

La salida muestra que el usuario root creó el pool en espejo con los discos /dev/ada0p1 y /dev/ada1p1. El hostname myzfsbox también se muestra con cada comando. La visualización del hostname se vuelve importante cuando se exporta el pool desde un sistema y se importa en otro. Es posible distinguir los comandos emitidos en el otro sistema por el hostname registrado para cada comando.

Combine ambas opciones en zpool history para dar la información más detallada posible para cualquier pool dado. El historial del pool proporciona información valiosa al rastrear las acciones realizadas o cuando se necesita una salida más detallada para depuración.

Un sistema de monitorización incorporado puede mostrar estadísticas de E/S del pool en tiempo real. Muestra la cantidad de espacio libre y utilizado en el pool, las operaciones de lectura y escritura realizadas por segundo y el ancho de banda de E/S utilizado. Por defecto, ZFS monitoriza y muestra todos los pools en el sistema. Proporcione un nombre de pool para limitar la monitorización a ese pool. Un ejemplo básico:

Para ver continuamente la actividad de E/S, especifique un número como último parámetro, indicando un intervalo en segundos para esperar entre actualizaciones. La siguiente línea de estadísticas se imprime después de cada intervalo. Presione Ctrl+C para detener esta monitorización continua. Dé un segundo número en la línea de comandos después del intervalo para especificar el número total de estadísticas a mostrar.

Muestre estadísticas de E/S aún más detalladas con -v. Cada dispositivo en el pool aparece con una línea de estadísticas. Esto es útil para ver las operaciones de lectura y escritura realizadas en cada dispositivo, y puede ayudar a determinar si algún dispositivo individual está ralentizando el pool. Este ejemplo muestra un pool en espejo con dos dispositivos:

zpool iostat ofrece varias vistas más profundas de la canalización de E/S. -l añade columnas de latencia promedio, dividiendo el tiempo total de espera en tiempo de disco y tiempo pasado en las diversas colas de E/S. -q muestra el número de operaciones pendientes y activas en cada cola por vdev. -w imprime histogramas de latencia completos, y -r imprime histogramas de tamaño de solicitud para cada vdev hoja.

Las columnas de latencia de -l facilitan detectar un solo disco lento que ralentiza todo un vdev:

En este ejemplo, ada2p1 necesita cientos de milisegundos de tiempo de disco para E/S que su socio de espejo ada1p1 completa en milisegundos de un solo dígito, mientras que ambos manejan un número similar de operaciones. Una escritura en el espejo solo se completa cuando el miembro más lento termina, por lo que la latencia de escritura de todo el vdev sigue a ada2p1. Una latencia alta con recuentos de operación normales, sin errores de lectura, escritura o suma de comprobación en zpool status, a menudo indica un disco que reintenta internamente y es candidato a reemplazo.

Los scripts que deben esperar a que finalice la actividad de fondo del pool pueden bloquearse en zpool wait:

El comando regresa una vez que ninguna de las actividades nombradas, como scrub, resilver, trim o remove, está en progreso. Véase zpool-wait(8) para la lista completa de actividades.

ZFS puede dividir un pool que consiste en uno o más vdevs en espejo en dos pools. A menos que se especifique lo contrario, ZFS desprende el último miembro de cada espejo y crea un nuevo pool que contiene los mismos datos. Asegúrese de hacer una prueba de simulación de la operación con -n primero. Esto muestra los detalles de la operación solicitada sin realizarla realmente. Esto ayuda a confirmar que la operación hará lo que el usuario pretende.

A diferencia de los discos tradicionales y los administradores de volúmenes, el espacio en ZFS no se preasigna. Con los sistemas de archivos tradicionales, después de particionar y asignar el espacio, no hay forma de añadir un nuevo sistema de archivos sin añadir un nuevo disco. Con ZFS, es posible crear nuevos sistemas de archivos en cualquier momento. Cada conjunto de datos tiene propiedades que incluyen características como compresión, deduplicación, almacenamiento en caché y cuotas, así como otras propiedades útiles como solo lectura, sensibilidad a mayúsculas, compartición de archivos en red y un punto de montaje. Anidar conjuntos de datos dentro de otros es posible y los conjuntos de datos hijos heredarán propiedades de sus ancestros. Delegar, replicar, instantánea, jail permite administrar y destruir cada conjunto de datos como una unidad. Crear un conjunto de datos separado para cada tipo o conjunto de archivos diferente tiene ventajas. Los inconvenientes de tener un gran número de conjuntos de datos son que algunos comandos como zfs list serán más lentos, y que el montaje de cientos o incluso miles de conjuntos de datos ralentizará el proceso de arranque de FreeBSD.

Cree un nuevo conjunto de datos y habilite compresión LZ4 en él:

Destruir un conjunto de datos es mucho más rápido que eliminar los archivos en el conjunto de datos, ya que no implica escanear los archivos y actualizar los metadatos correspondientes.

Destruya el conjunto de datos creado:

En las versiones modernas de ZFS, zfs destroy es asíncrono, y el espacio libre puede tardar minutos en aparecer en el grupo. Use zpool get freeing nombredegrupo para ver la propiedad freeing, que muestra cuánto espacio queda por reclamar en segundo plano. Use zpool wait -t free nombredegrupo para esperar hasta que la liberación en segundo plano se complete. Si hay conjuntos de datos secundarios, como instantáneas u otros conjuntos de datos, es imposible destruir el principal. Para destruir un conjunto de datos y sus secundarios, use -r para destruir recursivamente el conjunto de datos y sus secundarios. Use -n -v para listar los conjuntos de datos e instantáneas destruidos por esta operación, sin destruir realmente nada. El espacio reclamado al destruir instantáneas también se muestra.

Un volumen es un tipo especial de conjunto de datos. En lugar de montarse como un sistema de archivos, se expone como un dispositivo de bloques bajo /dev/zvol/nombredelgrupo/conjuntodedatos. Esto permite usar el volumen para otros sistemas de archivos, para respaldar los discos de una máquina virtual, o para ponerlo a disposición de otros hosts de red usando protocolos como iSCSI o HAST.

Formatee un volumen con cualquier sistema de archivos o sin sistema de archivos para almacenar datos en bruto. Para el usuario, un volumen aparece como un disco normal. Poner sistemas de archivos ordinarios en estos zvols proporciona características que los discos ordinarios o sistemas de archivos no tienen. Por ejemplo, usar la propiedad de compresión en un volumen de 250 MB permite crear un sistema de archivos FAT comprimido.

Crear un volumen reserva suficiente espacio en el grupo para contener el tamaño completo del volumen. Para omitir esa reserva, cree un volumen disperso, también conocido como volumen con aprovisionamiento fino, con -s:

Los volúmenes dispersos permiten comprometer más espacio del que el grupo tiene realmente. Las escrituras en un volumen disperso pueden fallar con ENOSPC cuando el grupo se queda sin espacio, así que use volúmenes dispersos solo donde el consumidor del volumen tolere errores de escritura.

La propiedad volmode controla cómo ZFS expone un volumen al sistema operativo. Establecerla en full expone el volumen como un proveedor GEOM con funcionalidad máxima, y geom es un alias para full. Establecerla en dev expone el volumen como un nodo de dispositivo plano, ocultando cualquier partición que contenga. Los volúmenes con volmode establecido en none no se exponen fuera de ZFS en absoluto, pero aún admiten instantáneas, clones y replicación, lo que los hace útiles como objetivos de replicación. La propiedad por defecto es default, que defería al ajuste global del sistema zvol_volmode descrito en zfs(4).

Los volúmenes funcionan bien como discos virtuales para máquinas virtuales bhyve(8) y como almacenamiento de respaldo para extensiones iSCSI: declare el dispositivo de volumen como un LUN en ctl.conf(5) y sírvalo con ctld(8).

Destruir un volumen es muy similar a destruir un conjunto de datos de sistema de archivos regular. La operación es casi instantánea, pero puede tardar minutos en reclamar el espacio libre en segundo plano.

Para cambiar el nombre de un conjunto de datos, use zfs rename. Para cambiar el principal de un conjunto de datos, use también este comando. Renombrar un conjunto de datos para tener un conjunto de datos principal diferente cambiará el valor de aquellas propiedades heredadas del conjunto de datos principal. Renombrar un conjunto de datos lo desmonta y luego lo vuelve a montar en la nueva ubicación (heredada del nuevo conjunto de datos principal). Para prevenir este comportamiento, use -u.

Renombre un conjunto de datos y muévalo para que esté bajo un conjunto de datos principal diferente:

Renombrar instantáneas usa el mismo comando. Debido a la naturaleza de las instantáneas, el renombrado no puede cambiar su conjunto de datos principal. Para renombrar una instantánea recursiva, especifique -r; esto también renombrará todas las instantáneas con el mismo nombre en los conjuntos de datos secundarios.

Cada conjunto de datos ZFS tiene propiedades que controlan su comportamiento. La mayoría de las propiedades se heredan automáticamente del conjunto de datos principal, pero se pueden anular localmente. Establezca una propiedad en un conjunto de datos con zfs set propiedad=valor conjunto_de_datos. La mayoría de las propiedades tienen un conjunto limitado de valores válidos, zfs get mostrará cada propiedad posible y los valores válidos. Usar zfs inherit revierte la mayoría de las propiedades a sus valores heredados. También son posibles las propiedades definidas por el usuario. Se convierten en parte de la configuración del conjunto de datos y proporcionan más información sobre el conjunto de datos o su contenido. Para distinguir estas propiedades personalizadas de las suministradas como parte de ZFS, use dos puntos (:) para crear un espacio de nombres personalizado para la propiedad.

Para eliminar una propiedad personalizada, use zfs inherit con -r. Si la propiedad personalizada no está definida en ninguno de los conjuntos de datos principales, esta opción la elimina (pero el historial del grupo aún registra el cambio).

ZFS en FreeBSD almacena ACLs de estilo NFSv4 de forma nativa; la propiedad acltype del conjunto de datos tiene como valor predeterminado nfsv4. Cada archivo y directorio puede llevar una lista de control de acceso junto con los bits de permiso tradicionales, brindando un control más granular que el modelo propietario/grupo/otros. Muestre y edite estas listas con getfacl(1) y setfacl(1).

Muestre la ACL de un archivo:

Conceda a un usuario adicional acceso de escritura agregando una entrada allow:

Dos propiedades del conjunto de datos controlan cómo las ACLs interactúan con el manejo de permisos tradicional. La propiedad aclmode (discard, groupmask, passthrough, o restricted) gobierna lo que sucede con la ACL cuando chmod(1) cambia los bits de permiso de un archivo. Con el valor predeterminado, discard, chmod elimina todas las entradas de ACL que no representan el nuevo modo de archivo. La propiedad aclinherit (discard, noallow, restricted, passthrough, o passthrough-x) gobierna qué entradas de ACL heredan los nuevos archivos y directorios de su directorio principal. Con el valor predeterminado, restricted, las entradas heredadas pierden los permisos write_acl y write_owner.

Consulte setfacl(1) y zfsprops(7) para la sintaxis completa de entrada y las descripciones de propiedades.

Las instantáneas son una de las características más potentes de ZFS. Una instantánea proporciona una copia de solo lectura, puntual del conjunto de datos. Con Copy-On-Write (COW), ZFS crea instantáneas rápidamente al preservar versiones más antiguas de los datos en disco. Si no existen instantáneas, ZFS reclama espacio para uso futuro cuando se reescriben o eliminan datos. Las instantáneas preservan espacio en disco al registrar solo las diferencias entre el conjunto de datos actual y una versión anterior. Permitiendo instantáneas en conjuntos de datos completos, no en archivos o directorios individuales. Una instantánea de un conjunto de datos duplica todo lo contenido en él. Esto incluye las propiedades del sistema de archivos, archivos, directorios, permisos, etc. Las instantáneas no usan espacio extra cuando se crean por primera vez, pero consumen espacio a medida que cambian los bloques a los que hacen referencia. Las instantáneas recursivas tomadas con -r crean instantáneas con el mismo nombre en el conjunto de datos y sus secundarios, proporcionando una instantánea puntual consistente de los sistemas de archivos. Esto puede ser importante cuando una aplicación tiene archivos en conjuntos de datos relacionados o que dependen unos de otros. Sin instantáneas, una copia de seguridad tendría copias de los archivos de diferentes puntos en el tiempo.

Las instantáneas en ZFS proporcionan una variedad de características que incluso otros sistemas de archivos con funcionalidad de instantáneas carecen. Un ejemplo típico del uso de instantáneas es como una forma rápida de respaldar el estado actual del sistema de archivos al realizar una acción riesgosa como una instalación de software o una actualización del sistema. Si la acción falla, revertir a la instantánea devuelve el sistema al mismo estado en que se creó la instantánea. Si la actualización fue exitosa, elimine la instantánea para liberar espacio. Sin instantáneas, una actualización fallida a menudo requiere restaurar copias de seguridad, lo cual es tedioso, consume tiempo y puede requerir tiempo de inactividad durante el cual el sistema es inutilizable. Revertir a instantáneas es rápido, incluso mientras el sistema se ejecuta en operación normal, con poco o ningún tiempo de inactividad. El ahorro de tiempo es enorme con sistemas de almacenamiento de múltiples terabytes considerando el tiempo requerido para copiar los datos desde la copia de seguridad. Las instantáneas no son un reemplazo para una copia de seguridad completa de un grupo, pero ofrecen una forma rápida y fácil de almacenar una copia de un conjunto de datos en un momento específico.

Un marcador registra el punto en el tiempo en que se creó una instantánea, sin conservar ninguno de los datos de la instantánea. Los marcadores consumen casi ningún espacio, sin importar cuánto cambie el conjunto de datos después. Como una instantánea, un marcador puede servir como fuente de un zfs send incremental. A diferencia de una instantánea, no impide que ZFS libere los datos antiguos. Esta combinación hace que los marcadores sean útiles para la replicación incremental: después de enviar una instantánea a otro pool, marcarla y destruirla en el lado de envío, reclamando el espacio mientras el lado receptor mantiene su copia de la instantánea. Consulte Respaldos Incrementales para el flujo de trabajo de replicación en sí.

Cree un marcador a partir de una instantánea con zfs bookmark. Los nombres de marcadores usan # como separador entre el nombre del conjunto de datos y el nombre del marcador, de la misma manera que los nombres de instantáneas usan @.

Enumere los marcadores con zfs list -t bookmark:

Cuando llega el momento para el próximo respaldo incremental, tome una nueva instantánea y use el marcador como fuente incremental:

Esto funciona porque el pool receptor aún tiene la instantánea backup/data@snap1 que coincide con el marcador. Los marcadores sirven solo como fuentes incrementales. Montar un marcador, retroceder a él o restaurar archivos desde él es imposible, ya que no contiene datos. Consulte zfs-bookmark(8) para obtener más información.

Un clon es una copia de una instantánea tratada más como un conjunto de datos regular. A diferencia de una instantánea, un clon es escribible y montable, y tiene sus propias propiedades. Después de crear un clon usando zfs clone, destruir la instantánea originadora es imposible. Para revertir la relación hijo/padre entre el clon y la instantánea use zfs promote. Promover un clon hace que la instantánea se convierta en un hijo del clon, en lugar del conjunto de datos padre original. Esto cambiará cómo ZFS contabiliza el espacio, pero no cambiará realmente la cantidad de espacio consumido. Es posible montar el clon en cualquier lugar dentro de la jerarquía del sistema de archivos ZFS, no solo debajo de la ubicación original de la instantánea.

Para mostrar la función de clon use este conjunto de datos de ejemplo:

Un uso típico para los clones es experimentar con un conjunto de datos específico mientras se mantiene la instantánea disponible para retroceder en caso de que algo salga mal. Dado que las instantáneas no pueden cambiar, cree un clon de lectura/escritura de una instantánea. Después de lograr el resultado deseado en el clon, promueva el clon a un conjunto de datos y elimine el sistema de archivos antiguo. Eliminar el conjunto de datos padre no es estrictamente necesario, ya que el clon y el conjunto de datos pueden coexistir sin problemas.

Crear un clon lo convierte en una copia exacta del estado en el que se encontraba el conjunto de datos al tomar la instantánea. Ahora es posible cambiar el clon de forma independiente de su conjunto de datos de origen. La conexión entre los dos es la instantánea. ZFS registra esta conexión en la propiedad origin. Promover el clon con zfs promote convierte al clon en un conjunto de datos independiente. Esto elimina el valor de la propiedad origin y desconecta el nuevo conjunto de datos independiente de la instantánea. Este ejemplo lo muestra:

Después de realizar algunos cambios, como copiar loader.conf al clon promovido, por ejemplo, el directorio antiguo se vuelve obsoleto en este caso. En su lugar, el clon promovido puede reemplazarlo. Para hacer esto, primero zfs destroy el conjunto de datos antiguo y luego zfs rename el clon al nombre del conjunto de datos antiguo (o a un nombre completamente diferente).

La instantánea clonada es ahora un conjunto de datos ordinario. Contiene todos los datos de la instantánea original más los archivos añadidos a ella como loader.conf. Los clones proporcionan características útiles a los usuarios de ZFS en diferentes escenarios. Por ejemplo, proporcionar jaulas como instantáneas que contienen diferentes conjuntos de aplicaciones instaladas. Los usuarios pueden clonar estas instantáneas y añadir sus propias aplicaciones como consideren oportuno. Una vez satisfechos con los cambios, promueven los clones a conjuntos de datos completos y los proporcionan a los usuarios finales para que trabajen con ellos como lo harían con un conjunto de datos real. Esto ahorra tiempo y sobrecarga administrativa al proporcionar estas jaulas.

Clonación de bloques lleva la escritura en copia (copy-on-write) a copias de archivos individuales. Cuando está habilitada, copiar un archivo con cp(1) no duplica los datos del archivo. En su lugar, el nuevo archivo hace referencia a los mismos bloques que el original, y ZFS escribe nuevos bloques solo cuando cualquiera de los archivos cambia posteriormente. cp(1) realiza copias con copy_file_range(2), que ZFS convierte en operaciones de clonación de bloques, haciendo que las copias dentro de un grupo sean casi instantáneas y no consuman espacio adicional al principio.

A diferencia de deduplicación, la clonación de bloques no mantiene una tabla de comprobaciones que consuma memoria. El intercambio ocurre solo en el momento de la copia, y escribir datos idénticos en operaciones separadas aún los almacena dos veces. A diferencia de clones, la clonación de bloques no requiere una instantánea, funciona en archivos individuales en lugar de conjuntos de datos completos y no deja una relación de origin detrás.

La clonación de bloques requiere la característica de grupo block_cloning de OpenZFS 2.2, incluida por primera vez en FreeBSD 14.0 (ver zpool-features(7)). El sysctl(8) vfs.zfs.bclone_enabled controla si ZFS realmente crea clones de bloques. Por defecto es 0 en FreeBSD 14.x y 1 en FreeBSD 15.0. Mientras el sysctl sea 0, copy_file_range() recurre a una copia ordinaria. Para habilitar la clonación de bloques en FreeBSD 14.x:

Para mantener la configuración tras reinicios, añada esta línea a /etc/sysctl.conf:

Las propiedades de grupo bcloneused, bclonesaved y bcloneratio muestran el espacio utilizado por bloques clonados, el espacio ahorrado por la clonación y la proporción de ahorro resultante:

Mantener los datos en un solo grupo en una sola ubicación los expone a riesgos como robo y desastres naturales o humanos. Hacer copias de seguridad regulares de todo el grupo es vital. ZFS proporciona una función de serialización integrada que puede enviar una representación de flujo de los datos a la salida estándar. Usando esta función, es posible almacenar estos datos en otro grupo conectado al sistema local, así como enviarlos a través de una red a otro sistema. Las instantáneas son la base para esta replicación (ver la sección sobre Instantáneas de ZFS). Los comandos utilizados para replicar datos son zfs send y zfs receive.

Estos ejemplos muestran la replicación de ZFS con estos dos grupos:

El grupo llamado mypool es el grupo principal donde se escriben y leen datos de forma regular. Se utiliza un segundo grupo de reserva backup en caso de que el grupo principal no esté disponible. Tenga en cuenta que esta conmutación por error no la hace ZFS automáticamente, sino que debe ser realizada manualmente por un administrador del sistema cuando sea necesario. Use una instantánea para proporcionar una versión consistente del sistema de archivos para replicar. Después de crear una instantánea de mypool, cópiela al grupo backup replicando instantáneas. Esto no incluye los cambios realizados desde la instantánea más reciente.

Ahora que existe una instantánea, use zfs send para crear un flujo que represente el contenido de la instantánea. Almacene este flujo como un archivo o recíbalo en otro grupo. Escribir el flujo a la salida estándar, pero redirigir a un archivo o tubería o aparecerá un error:

Para hacer una copia de seguridad de un conjunto de datos con zfs send, redirija a un archivo ubicado en el grupo de respaldo montado. Asegúrese de que el grupo tenga suficiente espacio libre para acomodar el tamaño de la instantánea enviada, lo que significa los datos contenidos en la instantánea, no los cambios desde la instantánea anterior.

El zfs send transfirió todos los datos en la instantánea llamada backup1 al grupo llamado backup. Para crear y enviar estas instantáneas automáticamente, use un trabajo de cron(8).

En lugar de almacenar las copias de seguridad como archivos comprimidos, ZFS puede recibirlas como un sistema de archivos en vivo, permitiendo el acceso directo a los datos respaldados. Para llegar a los datos reales contenidos en esos flujos, use zfs receive para transformar los flujos de nuevo en archivos y directorios. El ejemplo siguiente combina zfs send y zfs receive usando una tubería para copiar los datos de un grupo a otro. Use los datos directamente en el grupo receptor una vez que la transferencia se complete. Solo es posible replicar un conjunto de datos a un conjunto de datos vacío.

Utilice las cuotas de dataset para restringir la cantidad de espacio consumido por un dataset en particular. Las cuotas de referencia funcionan de manera muy similar, pero cuentan el espacio utilizado por el propio dataset, excluyendo los snapshots y los datasets hijos. De manera similar, utilice las cuotas de usuario y de grupo para evitar que los usuarios o grupos agoten todo el espacio en el pool o dataset. Las cuotas de proyecto, descritas a continuación, restringen en su lugar el espacio consumido por un árbol de directorios arbitrario.

Los siguientes ejemplos asumen que los usuarios ya existen en el sistema. Antes de añadir un usuario al sistema, asegúrese de crear primero su dataset de inicio y establecer el mountpoint en /home/bob. Luego, cree el usuario y haga que el directorio de inicio apunte a la ubicación del mountpoint del dataset. Esto establecerá correctamente los permisos de propietario y grupo sin ocultar ninguna ruta de directorio de inicio preexistente que pudiera existir.

Para aplicar una cuota de dataset de 10 GB para storage/home/bob:

Para aplicar una cuota de referencia de 10 GB para storage/home/bob:

Para eliminar una cuota de 10 GB para storage/home/bob:

El formato general es userquota@user=size, y el nombre del usuario debe estar en uno de estos formatos:

Por ejemplo, para aplicar una cuota de usuario de 50 GB para el usuario llamado joe:

Para eliminar cualquier cuota:

El formato general para establecer una cuota de grupo es: groupquota@group=size.

Para establecer la cuota para el grupo firstgroup en 50 GB, utilice:

Para eliminar la cuota del grupo firstgroup, o para asegurarse de que no haya ninguna establecida, utilice en su lugar:

Al igual que con la propiedad de cuota de usuario, los usuarios que no son root pueden ver las cuotas asociadas a los grupos a los que pertenecen. Un usuario con el privilegio groupquota o root puede ver y establecer todas las cuotas para todos los grupos.

Para mostrar la cantidad de espacio utilizado por cada usuario en un sistema de archivos o snapshot junto con cualquier cuota, utilice zfs userspace. Para obtener información de grupos, utilice zfs groupspace. Para obtener más información sobre las opciones soportadas o cómo mostrar opciones específicas de forma aislada, consulte zfs-userspace(8).

Los usuarios privilegiados y root pueden listar la cuota para storage/home/bob utilizando:

Las reservas garantizan una cantidad de espacio siempre disponible en un dataset. El espacio reservado no estará disponible para ningún otro dataset. Esta útil característica asegura que haya espacio libre disponible para un dataset importante o archivos de registro.

El formato general de la propiedad reservation es reservation=size, por lo que para establecer una reserva de 10 GB en storage/home/bob, utilice:

Para borrar cualquier reserva:

El mismo principio se aplica a la propiedad refreservation para establecer una reserva de referencia, con el formato general refreservation=size.

Este comando muestra cualquier reserva o reserva de referencia que exista en storage/home/bob:

ZFS proporciona compresión transparente. Comprimir los datos escritos a nivel de bloque ahorra espacio y también aumenta el rendimiento del disco. Si los datos se comprimen en un 25%, los datos comprimidos se escriben en el disco a la misma velocidad que la versión sin comprimir, lo que resulta en una velocidad de escritura efectiva del 125%. La compresión también puede ser una gran alternativa a la deduplicación porque no requiere memoria adicional.

ZFS ofrece diferentes algoritmos de compresión, cada uno con diferentes compromisos. En OpenZFS 2.2 y versiones posteriores, los pools y datasets recién creados tienen por defecto compression=on, lo que selecciona LZ4. LZ4 comprime todo el pool sin el gran impacto en el rendimiento de otros algoritmos. La mayor ventaja de LZ4 es la característica de early abort. Si LZ4 no logra al menos un 12,5% de compresión en la parte de la cabecera de los datos, ZFS escribe el bloque sin comprimir para evitar desperdiciar ciclos de CPU intentando comprimir datos que ya están comprimidos o que son incompresibles. Cambiar la propiedad compression afecta solo a las nuevas escrituras; los datos existentes mantienen su antigua codificación hasta que se reescriben (consulte Reescritura de datos existentes). Para obtener detalles sobre los diferentes algoritmos de compresión disponibles en ZFS, consulte la entrada Compresión en la sección de terminología.

El administrador puede ver la efectividad de la compresión utilizando las propiedades del dataset.

El dataset está utilizando 449 GB de espacio (la propiedad used). Sin compresión, habría ocupado 496 GB de espacio (la propiedad logicalused). Esto da como resultado una tasa de compresión de 1.11:1.

La compresión puede tener un efecto secundario inesperado cuando se combina con las cuotas de usuario. Las cuotas de usuario restringen la cantidad de espacio real que un usuario consume en un dataset después de la compresión. Si un usuario tiene una cuota de 10 GB y escribe 10 GB de datos compresibles, todavía podrá almacenar más datos. Si más tarde actualiza un archivo, por ejemplo una base de datos, con datos más o menos compresibles, la cantidad de espacio disponible para él cambiará. Esto puede resultar en la extraña situación en la que un usuario no aumentó la cantidad real de datos (la propiedad logicalused), pero el cambio en la compresión hizo que alcanzara su límite de cuota.

La compresión puede tener una interacción inesperada similar con las copias de seguridad. Las cuotas se utilizan a menudo para limitar el almacenamiento de datos y asegurar que haya suficiente espacio de copia de seguridad disponible. Dado que las cuotas no consideran la compresión, ZFS puede escribir más datos de los que cabrían en copias de seguridad sin comprimir.

OpenZFS 2.0 añadió el algoritmo de compresión Zstandard (Zstd). Zstd ofrece tasas de compresión más altas que el LZ4 predeterminado, al tiempo que ofrece velocidades mucho mayores que la alternativa, gzip.

Zstd proporciona una gran selección de niveles de compresión, ofreciendo un control detallado sobre el rendimiento frente a la tasa de compresión. Una de las principales ventajas de Zstd es que la velocidad de descompresión es independiente del nivel de compresión. Para los datos que se escriben una vez pero se leen a menudo, Zstd permite el uso de los niveles de compresión más altos sin penalización en el rendimiento de lectura.

Incluso con actualizaciones frecuentes de datos, habilitar la compresión a menudo proporciona un mayor rendimiento. Una de las mayores ventajas proviene de la característica ARC comprimida. La Adaptive Replacement Cache (ARC) de ZFS almacena en caché la versión comprimida de los datos en la RAM, descomprimiéndola cada vez. Esto permite que la misma cantidad de RAM almacene más datos y metadatos, aumentando la tasa de aciertos de la caché.

ZFS ofrece 19 niveles de compresión Zstd, cada uno ofreciendo incrementalmente más ahorro de espacio a cambio de una compresión más lenta. El nivel predeterminado es zstd-3 y ofrece una mayor compresión que LZ4 sin ser mucho más lento. Los niveles superiores a 10 requieren grandes cantidades de memoria para comprimir cada bloque y los sistemas con menos de 16 GB de RAM no deberían utilizarlos. ZFS también utiliza una selección de los niveles fast de Zstd, que se vuelven correspondientemente más rápidos pero soportan tasas de compresión más bajas. ZFS soporta desde zstd-fast-1 hasta zstd-fast-10, desde zstd-fast-20 hasta zstd-fast-100 en incrementos de 10, y zstd-fast-500 y zstd-fast-1000 que proporcionan una compresión mínima, pero ofrecen un alto rendimiento.

Si ZFS no puede obtener la memoria requerida para comprimir un bloque con Zstd, recurrirá a almacenar el bloque sin comprimir. Es poco probable que esto suceda excepto en los niveles más altos de Zstd en sistemas con memoria limitada. ZFS cuenta con qué frecuencia ha ocurrido esto desde que se cargó el módulo ZFS con kstat.zfs.misc.zstd.compress_alloc_fail.

Propiedades como compression, checksum, dedup y copies afectan únicamente a los datos recién escritos. Cambiarlas deja los bloques existentes almacenados tal como estaban, y aplicar los nuevos valores tradicionalmente requería un ciclo de envío/recepción (send/receive) o copiar cada archivo de un lado a otro. En su lugar, zfs rewrite reescribe los bloques de los archivos existentes en su lugar, como si se leyeran y escribieran de nuevo atómicamente, de modo que los valores actuales de las propiedades surten efecto sin esas soluciones alternativas.

El comando opera sobre archivos y directorios en lugar de nombres de dataset. Para aplicar un algoritmo de compresión recién elegido a todo un dataset, hágalo de forma recursiva desde su punto de montaje:

Añadir -v imprime el nombre de cada archivo reescrito. -x evita que la recursión cruce los puntos de montaje hacia los datasets hijos, y -o y -l restringen la reescritura a un rango de bytes dentro de un archivo. Los cambios de propiedades que alterarían el tamaño del bloque lógico, como recordsize, no tienen efecto en los archivos reescritos.

Los bloques reescritos son bloques nuevos: los snapshots tomados antes de la reescritura siguen haciendo referencia a las copias antiguas, por lo que el uso del espacio puede crecer hasta que esos snapshots se destruyan. zfs rewrite no funciona a través de snapshots por la misma razón. Consulte zfs-rewrite(8) para obtener más detalles.

Cuando está habilitada, la deduplicación utiliza el checksum de cada bloque para detectar bloques duplicados. Cuando un nuevo bloque es un duplicado de un bloque existente, ZFS escribe una nueva referencia a los datos existentes en lugar de todo el bloque duplicado. Son posibles enormes ahorros de espacio si los datos contienen muchos archivos duplicados o información repetida. Advertencia: la deduplicación requiere una gran cantidad de memoria, y habilitar la compresión en su lugar proporciona la mayor parte del ahorro de espacio sin el coste adicional.

dedup es una propiedad del dataset, no una propiedad del pool. Para activar la deduplicación, establézcala en un dataset:

Este ejemplo establece la propiedad en el dataset raíz del pool pool, por lo que cada dataset en el pool la hereda. Limitar la deduplicación a los datasets que realmente almacenan datos con muchos duplicados mantiene la tabla de deduplicación más pequeña.

La deduplicación solo afecta a los nuevos datos escritos en el dataset. El mero hecho de activar esta opción no deduplicará los datos ya escritos. En FreeBSD 15.0, zfs rewrite puede reescribir los datos existentes para que pasen por la deduplicación. Un pool con una propiedad de deduplicación recién activada se verá como en este ejemplo:

La columna DEDUP muestra la tasa real de deduplicación para el pool. Un valor de 1.00x muestra que los datos aún no se han deduplicado. El siguiente ejemplo copia algunos binarios del sistema tres veces en diferentes directorios en el pool deduplicado creado anteriormente.

Para observar la deduplicación de datos redundantes, utilice:

La columna DEDUP muestra un factor de 3.00x. Detectar y deduplicar copias de los datos utiliza un tercio del espacio. El potencial de ahorro de espacio puede ser enorme, pero tiene el coste de tener suficiente memoria para realizar un seguimiento de los bloques deduplicados. ZFS almacena una entrada para cada bloque deduplicado en la tabla de deduplicación (DDT). Una regla general es de 5 a 6 GB de RAM por cada 1 TB de datos deduplicados. Cuando la tabla ya no cabe en la memoria, cada escritura fuerza lecturas de las entradas de la tabla desde el disco, y el rendimiento se degrada drásticamente.

La deduplicación no siempre es beneficiosa cuando los datos en un pool no son redundantes. ZFS puede mostrar el ahorro de espacio potencial simulando la deduplicación en un pool existente:

Una vez que zdb -S termina de analizar el pool, muestra la tasa de reducción de espacio que se lograría al activar la deduplicación. En este caso, 1.16 es una tasa de ahorro de espacio deficiente proporcionada principalmente por la compresión. Activar la deduplicación en este pool no ahorraría ninguna cantidad de espacio, y no compensa la cantidad de memoria requerida para habilitar la deduplicación. Utilizando la fórmula ratio = dedup * compress / copies, los administradores de sistemas pueden planificar la asignación de almacenamiento, decidiendo si la carga de trabajo contendrá suficientes bloques duplicados para justificar los requisitos de memoria. Si los datos son razonablemente compresibles, el ahorro de espacio puede ser bueno.

Fast dedup, una implementación rediseñada que reduce estos costes, requiere OpenZFS 2.3 o posterior, disponible por primera vez en FreeBSD 15.0. Fast dedup agrupa las actualizaciones de la tabla de deduplicación en un registro en disco y las vuelca a la tabla en segundo plano, reduciendo la E/S aleatoria que hacía lenta a la deduplicación clásica. La propiedad del pool dedup_table_quota establece un límite en el tamaño en disco de la tabla; ZFS deja de añadir nuevas entradas una vez que el pool alcanza el límite, y con el valor predeterminado de auto el tamaño de un vdev de dedup dedicado sirve como cuota. La propiedad de solo lectura del pool dedup_table_size informa del tamaño actual de la tabla. zpool ddtprune -p 30 pool elimina el 30% más antiguo de las entradas de la tabla que no proporcionan ningún ahorro porque solo un único bloque hace referencia a ellas; -d days en su lugar poda las entradas de referencia única más antiguas que el número de días indicado. zpool status -DD pool muestra las estadísticas de la tabla de deduplicación, incluyendo un histograma de bloques por recuento de referencias. Almacenar la tabla en un dedup vdev dedicado compuesto por dispositivos rápidos mantiene las búsquedas rápidas incluso cuando la tabla supera la memoria RAM.

Una buena práctica es habilitar primero la compresión, ya que la compresión también proporciona un rendimiento mucho mayor. Habilite la deduplicación en los casos en que los ahorros sean considerables y con suficiente memoria disponible para la DDT.

Utilice zfs jail y la propiedad jailed correspondiente para delegar un dataset de ZFS a una Jail. zfs jail jailid adjunta un dataset a la jail especificada, y zfs unjail lo desvincula. Para controlar el dataset desde dentro de una jail, establezca la propiedad jailed. ZFS prohíbe montar un dataset enjaulado en el host porque puede tener puntos de montaje que comprometerían la seguridad del host.

Un dataset delegado cede el control de todo un subárbol al administrador de la jail, quien puede montarlo, crear datasets hijos, tomar snapshots y cambiar propiedades, todo ello confinado a ese subárbol. Para que esto funcione, la jail necesita tener habilitados los parámetros allow.mount y allow.mount.zfs y el parámetro enforce_statfs establecido en un valor inferior a 2. Consulte jail(8) para obtener detalles sobre estos parámetros.

Este ejemplo crea un dataset, lo marca como enjaulado y lo adjunta a la jail en ejecución myjail:

El dataset aparece entonces en zfs list dentro de la jail y es administrable allí. zfs unjail myjail mypool/jaildata devuelve el control al host. Consulte zfs-jail(8) para obtener más información.

A partir de FreeBSD 15.0, jail(8) automatiza la vinculación. Enumere los datasets a delegar en el parámetro de jail zfs.dataset, y jail(8) los adjuntará cuando se inicie la jail. Los datasets ya deben tener establecido jailed=on, y el parámetro requiere allow.mount.zfs. Una entrada en /etc/jail.conf que lo utilice se ve así:

Establecer el parámetro de jail zfs.mount_snapshot en 1 permite adicionalmente a los usuarios dentro de la jail acceder al contenido de los snapshots de ZFS bajo el directorio .zfs de los sistemas de archivos delegados.

zfs allow someuser create mydataset otorga al usuario especificado permiso para crear datasets hijos bajo el dataset padre seleccionado. Una advertencia: crear un nuevo dataset implica montarlo. Eso requiere establecer el sysctl(8) vfs.usermount de FreeBSD en 1 para permitir que los usuarios que no son root monten un sistema de archivos. Otra restricción destinada a prevenir abusos: los usuarios que no son root deben ser los propietarios del punto de montaje donde se montará el sistema de archivos.

zfs allow someuser allow mydataset otorga al usuario especificado la capacidad de asignar cualquier permiso que tenga sobre el dataset de destino, o sus hijos, a otros usuarios. Si un usuario tiene el permiso snapshot y el permiso allow, ese usuario puede entonces conceder el permiso snapshot a otros usuarios.

El cifrado de ZFS se habilita estableciendo la propiedad encryption=on al crear un dataset. Establecer esta propiedad fuera de un comando zfs create no habilita el cifrado de forma retroactiva, ya que solo tiene efecto durante la creación del dataset. En el siguiente ejemplo, se utiliza una frase de contraseña al montar el dataset cifrado después de haber sido creado.

Si la frase de contraseña tiene menos de ocho caracteres, ZFS la rechaza y no crea el dataset. Después de que la frase de contraseña se haya introducido correctamente dos veces, ZFS crea y monta el dataset en el pool.

Cualquier dato almacenado en el dataset cifrado permanece cifrado mientras resida allí. Copiar datos de un dataset cifrado a una ubicación sin cifrar descifra los datos durante la operación de copia. El dataset recién creado se puede montar entonces en una ubicación diferente si es necesario.

Como era de esperar, los datos están actualmente disponibles para lectura y escritura por cualquiera que tenga acceso al dataset.

Listar las propiedades de cifrado nativo de ZFS para un dataset se realiza con el siguiente comando:

La propiedad encryption muestra aes-256-gcm, que es actualmente el método de cifrado predeterminado utilizado por ZFS. Como indica la columna SOURCE, ni esta propiedad ni la propiedad keyformat se pueden cambiar utilizando zfs set después de que se haya creado el dataset. Consulte la sección changing the encryption key para obtener información sobre cómo modificar algunas de estas propiedades. La siguiente tabla enumera las propiedades relacionadas con el cifrado utilizadas por ZFS:

Proteger los datos almacenados en un dataset cifrado requiere dos pasos: primero desmontar el dataset, luego descargar la clave de cifrado de la memoria. Esta distinción es importante. Un dataset desmontado no está protegido si su clave de cifrado permanece cargada en la memoria. Ejecute siempre zfs unload-key para proteger los datos. Para acceder al dataset de nuevo, cargue la clave y proporcione la frase de contraseña como se describe en la sección loading the encryption key. ZFS impide que zfs unload-key se ejecute mientras el dataset todavía está montado.

Ejecutar zfs unload-key varias veces da como resultado un error que indica que la clave ya ha sido descargada.

Antes de que un dataset cifrado pueda ser utilizado como cualquier otro dataset, su clave de cifrado debe ser cargada y se debe proporcionar la frase de contraseña. En este punto, la propiedad keystatus todavía está establecida en unavailable, y el montaje del dataset falla porque la clave aún no se ha cargado:

Esto indica que el dataset está cifrado y requiere una clave de cifrado. Para montar el dataset, ejecute zfs load-key y proporcione la frase de contraseña cuando se le solicite:

A continuación, monte el dataset para hacerlo accesible a través de la jerarquía del sistema de archivos:

Para cargar múltiples claves de cifrado de forma recursiva, especifique la opción -r con zfs load-key. Si una clave ya ha sido cargada, ZFS lo informa con un mensaje de error.

La propiedad keystatus también confirma que la clave ha sido cargada al informar el valor available. Para verificar si una frase de contraseña es correcta sin cargar la clave, utilice la opción -n para realizar una prueba en seco (dry run).

ZFS también soporta el cambio de claves de cifrado, como reemplazar una frase de contraseña. Esta operación no requiere volver a cifrar el dataset. Ejecute el siguiente comando para cambiar la frase de contraseña de cifrado:

Ejecutar zfs change-key requiere que la clave actual esté cargada. Si no lo está, ZFS sigue solicitando la nueva clave pero luego muestra una advertencia de que la clave actual no ha sido cargada.

El comando zfs change-key también puede modificar las propiedades keylocation, keyformat y pbkdf2iters especificándolas con la opción -o. Ejecutar zfs change-key en un dataset hijo cifrado lo convierte en una raíz de cifrado (encryption root) si aún no lo es. Para evitar este comportamiento y continuar heredando la clave del padre, especifique la opción -i.

Tenga en cuenta que cambiar la clave de cifrado de un dataset padre también cambia la clave para los datasets hijos que la heredan. En consecuencia, esos datasets hijos continúan utilizando la clave de cifrado del padre. Si un dataset hijo debe utilizar una clave diferente, especifique un keyformat diferente al crearlo o ejecute zfs change-key en el dataset hijo. Hacerlo crea una nueva raíz de cifrado para el hijo y rompe su herencia de cifrado del padre.

Los clones de ZFS de un dataset cifrado siempre utilizan la clave de cifrado de su dataset de origen. Como resultado, las propiedades keystatus, keyformat, keylocation y pbkdf2iters no se heredan como otras propiedades del dataset. En su lugar, utilizan los valores definidos por la raíz de cifrado. Para determinar la raíz de cifrado, utilice la propiedad de solo lectura encryptionroot.

Si un atacante compromete una clave de cifrado, cambiar la frase de contraseña con zfs change-key no protege necesariamente los datos existentes o recién escritos. Los nuevos datos continúan siendo cifrados con la misma clave maestra que los datos existentes. Si un atacante obtiene tanto una clave de usuario como su correspondiente clave maestra envuelta, ejecutar zfs change-key no sobrescribe la clave maestra anterior en el disco. Como resultado, la antigua clave maestra puede permanecer disponible para análisis forense durante un período indeterminado.

Si una clave maestra ha sido comprometida, la solución preferida es borrar de forma segura los dispositivos de almacenamiento subyacentes y crear un nuevo pool. Posteriormente, restaure los datos desde una copia de seguridad al nuevo pool. Alternativamente, cree un nuevo dataset cifrado, migre los datos utilizando zfs send y zfs receive, y luego ejecute zpool trim --secure para borrar el espacio liberado. Si el hardware subyacente no soporta TRIM seguro, utilice zpool initialize en su lugar.

La replicación de ZFS se basa en el envío de snapshots de datasets, que también se pueden crear a partir de datasets cifrados. Las instantáneas resultantes permanecen cifradas.

Además de enviar copias de seguridad cifradas a través de SSH, el uso de la opción -w (raw) con zfs send transfiere los bloques de datos cifrados al pool de destino. Un envío en bruto (raw) proporciona varias ventajas:

Para enviar la instantánea creada anteriormente como un flujo en bruto (raw) al dataset secret en el pool backup, introduzca el siguiente comando:

Sin la opción -w, zfs send transmite los datos de forma no cifrada. El sistema receptor puede entonces volver a cifrar los datos utilizando una clave diferente. Sin embargo, hacer esto impide futuros envíos incrementales en bruto a ese destino.

El script zfskeys de rc(8) carga las claves de cifrado en el arranque para los datasets cifrados cuya propiedad keylocation apunta a un archivo de clave con una URL file://. El script se ejecuta después de la importación del pool y antes de montar los sistemas de archivos, por lo que los datasets manejados de esta manera se montan automáticamente durante el inicio normal de ZFS. El script no maneja datasets con keylocation=prompt; cargue sus claves manualmente con zfs load-key después de que el sistema haya arrancado.

Para cambiar el dataset creado anteriormente de una frase de contraseña a un archivo de clave, genere 32 bytes de datos aleatorios como la nueva clave, restrinja el acceso al archivo de clave y cambie la clave de cifrado del dataset:

Habilite el script en /etc/rc.conf:

Por defecto, el script carga las claves de todos los datasets cifrados con una ubicación de clave file://. Para restringir la carga de claves a datasets específicos, enumérelos en zfskeys_datasets, separados por espacios:

Un entorno de arranque contiene únicamente los datasets bajo zroot/ROOT. En la disposición predeterminada Root-on-ZFS, esto incluye todo el sistema de archivos raíz con /usr/local y /var/db, por lo que los paquetes instalados y sus metadatos se revierten junto con el sistema operativo. Los datasets fuera de zroot/ROOT, como zroot/home, zroot/var/log y zroot/var/mail, son compartidos: cada entorno ve los mismos archivos, y activar un entorno más antiguo no los devuelve a un estado anterior.

Planifique la disposición de los datasets en torno a esta división antes de depender de los entornos de arranque. Los datos que deben sobrevivir a una reversión, como las bases de datos de una aplicación instalada desde paquetes, pertenecen a su propio dataset fuera de zroot/ROOT:

Con esta disposición, revertir a un entorno más antiguo devuelve los binarios del servidor de base de datos a su versión anterior, mientras que el contenido de la base de datos permanece intacto. Lo inverso también se cumple: los archivos escritos en datasets compartidos mientras se prueba un nuevo entorno persisten después de volver atrás, por lo que los entornos de arranque no reemplazan a las instantáneas de esos datasets.

Ajuste los parámetros configurables para que ZFS ofrezca el mejor rendimiento en diferentes cargas de trabajo. FreeBSD expone los parámetros configurables del kernel de ZFS como variables de sysctl(8) bajo vfs.zfs; zfs(4) documenta cada parámetro configurable y su valor predeterminado. Establezca los valores que deben aplicarse desde el arranque en /boot/loader.conf; ajuste los valores modificables en tiempo de ejecución con sysctl(8) y hágalos permanentes en /etc/sysctl.conf.

ZFS mantiene los datos y metadatos usados reciente y frecuentemente en la RAM en el ARC. El ARC crece bajo demanda hasta vfs.zfs.arc.max y se reduce de nuevo cuando otros programas necesitan memoria, por lo que en un servidor de almacenamiento dedicado es normal que la mayor parte de la RAM esté en uso. El ARC almacena los bloques en su forma comprimida en disco y los descomprime al acceder a ellos. Este ARC comprimido permite que la misma cantidad de RAM almacene en caché más datos, aumentando la tasa efectiva de aciertos.

top(1) muestra el tamaño actual del ARC en su línea de resumen de memoria. El árbol sysctl(8) kstat.zfs.misc.arcstats expone estadísticas detalladas, incluyendo el tamaño actual, el máximo objetivo y los contadores de aciertos y fallos:

filesystems/zfs-stats resume estas estadísticas en un informe legible por humanos.

El ARC cede memoria bajo presión, pero en sistemas que comparten RAM entre ZFS y otros grandes consumidores como bases de datos, máquinas virtuales o jails, la competencia puede causar un rendimiento desigual en ambos lados. Limitar el ARC deja una cantidad predecible de memoria para las otras cargas de trabajo. Por ejemplo, para limitar el ARC a 8 GB, añada esta línea a /boot/loader.conf:

Cambiar vfs.zfs.arc.max con sysctl(8) tiene efecto inmediatamente, aunque reducir un ARC caliente libera memoria gradualmente.

Cada pool tiene un ZIL. Las aplicaciones que solicitan semántica síncrona con fsync(2) o el indicador O_SYNC no obtienen una confirmación hasta que ZFS confirma el registro de intenciones correspondiente en el almacenamiento estable. Por defecto, el ZIL reside en los vdevs regulares del pool, por lo que cada escritura síncrona compite con la E/S normal del pool. Las escrituras asíncronas omiten el ZIL y se escriben con el siguiente transaction group.

Un vdev de log dedicado, a menudo llamado SLOG (registro separado), mueve el ZIL a un dispositivo rápido:

Un SLOG solo ayuda a las cargas de trabajo que generan muchas escrituras síncronas, como los servidores NFS y las bases de datos. No supone ninguna diferencia para las cargas de trabajo puramente asíncronas.

Unos pocos gigabytes de capacidad de SLOG son suficientes: el ZIL contiene como máximo unos pocos segundos de escrituras entrantes, aproximadamente el valor de un grupo de transacciones, antes de que ZFS escriba los datos en su ubicación final en el pool. Elija SSDs con protección contra pérdida de energía y baja latencia de escritura sostenida, y refleje los dispositivos de registro. ZFS lee el ZIL solo después de un fallo, por lo que perder un SLOG sin reflejar junto con un fallo del sistema hace que se pierdan las escrituras que fueron reconocidas pero aún no confirmadas en el pool.

La propiedad sync del dataset controla el comportamiento de la escritura síncrona:

La propiedad logbias ajusta cómo ZFS utiliza el registro: logbias=latency (el valor por defecto) favorece el SLOG para minimizar la latencia de confirmación, mientras que logbias=throughput escribe los datos síncronos directamente en el pool principal, reservando la capacidad del SLOG para los datasets sensibles a la latencia. Consulte zfsprops(7) para obtener más detalles.

La propiedad direct del dataset controla cómo ZFS maneja las peticiones realizadas con el indicador O_DIRECT:

La E/S directa evita las copias de memoria y la sobrecarga de almacenamiento en caché del ARC. En pools de dispositivos NVMe muy rápidos, esta sobrecarga puede dominar el coste de la propia E/S, y las aplicaciones que mantienen sus propias cachés, como las bases de datos, desperdician RAM al almacenar en caché los mismos datos dos veces. Para tales cargas de trabajo, la E/S directa puede aumentar el rendimiento y reducir el uso de memoria.

ZFS sigue verificando las sumas de comprobación para las lecturas y escrituras directas, por lo que la protección de la integridad de los datos no cambia. Las escrituras directas deben estar alineadas con el recordsize del dataset; ZFS redirige silenciosamente la porción no alineada de una petición a través del ARC. Consulte zfsprops(7) para conocer las reglas de alineación y restricciones completas.

La propiedad recordsize establece el bloque más grande que ZFS utiliza para almacenar un archivo en un dataset, 128 KB por defecto. Hacer coincidir el tamaño del bloque con el patrón de E/S de la carga de trabajo evita leer y escribir más datos de los que solicitó la aplicación.

Para las bases de datos que realizan pequeñas lecturas y escrituras aleatorias, establezca recordsize en el tamaño de página de la base de datos, típicamente 8 KB o 16 KB, antes de crear los archivos de la base de datos. Para los datasets que almacenan archivos multimedia grandes o flujos de copia de seguridad que se leen y escriben secuencialmente, recordsize=1M reduce la sobrecarga de metadatos y mejora la compresión. Los volúmenes utilizan en su lugar la propiedad volblocksize, que por defecto es de 16 KB y no puede cambiar después de crear el volumen.

Cambiar recordsize afecta solo a los archivos recién escritos; los archivos existentes mantienen su tamaño de bloque original. Ni siquiera zfs rewrite aplica un nuevo recordsize a los archivos existentes, ya que los cambios de propiedades que afectan al tamaño del bloque lógico no tienen efecto sobre los bloques reescritos; copie los archivos de nuevo para almacenarlos con el nuevo valor.