ZFS para principiantes

 (ikrima.dev)
2 puntos por GN⁺ 2023-09-06 | 1 comentarios | Compartir por WhatsApp
  • Guía introductoria surgida a partir de una falla de ZFS en FreeNAS, que organiza resolución de problemas, configuración de nuevos volúmenes y estrategias de respaldo, cubriendo en un mismo flujo la estructura y los comandos necesarios para operar ZFS por primera vez
  • ZFS ofrece a la vez sistema de archivos y administrador de volúmenes lógicos, y aunque comenzó en Sun Microsystems, en Linux y FreeBSD se usa principalmente el código de OpenZFS
  • Su estructura básica se divide en vdev, que agrupa discos físicos; pool, que reúne esos vdev; dataset, que cumple la función de sistema de archivos; y volume, con forma de dispositivo de bloques; RAIDZ-1/2/3 toleran la falla de 1, 2 y 3 discos respectivamente
  • Los comandos clave en la práctica son zpool create/status/list/import/export/destroy/scrub y zfs create/mount/list/get/set/snapshot/diff/rollback/send/recv/destroy, y para evitar problemas por cambios en el nombre del dispositivo se prefiere usar UUID del dispositivo
  • Los snapshots protegen de forma ligera el estado de un momento específico y pueden replicarse a otro pool o sistema con zfs send/recv, pero por sí solos difícilmente sustituyen un respaldo o DR

Conceptos básicos de ZFS

  • ZFS es tanto un sistema de archivos local, como ext4, NTFS o exFAT, como un administrador de volúmenes lógicos similar a LVM en Linux
  • Fue creado por Sun Microsystems, y su código fuente estuvo publicado bajo una licencia de código abierto hasta que Oracle adquirió Sun
  • Como el código ya había sido portado a varios sistemas operativos, después se creó el proyecto OpenZFS, y ese es el código que se usa en la mayoría de los sistemas tipo Unix, como Linux y FreeBSD
  • Está organizado desde la perspectiva de un principiante para ayudar a quien se encuentra con ZFS por primera vez a entender su estructura y sus comandos de operación

Componentes de ZFS

  • vdev se compone de uno o más discos físicos, y además de discos duros también puede incluir archivos
    • Puede combinarse en formas como mirror o RAIDZ
    • Existen 7 tipos de vdev, incluidos tipos importantes como hot spare, L2ARC y ZIL
  • pool se compone de uno o más vdev, y normalmente dentro del pool se crean volume o dataset
    • Al crear un pool con el comando zpool, también se definen los vdev
    • Se pueden mezclar varios tipos de vdev para configurar distintos niveles de RAIDZ
  • dataset es el componente de ZFS que corresponde al sistema de archivos
    • Permite configurar acceso de usuarios, quota, compresión, snapshot, etc.
  • volume es parecido a un dataset, pero ofrece una representación de dispositivo de bloques
    • Solo ofrece una parte de las funciones de un dataset
    • Es útil para ejecutar otro sistema de archivos sobre ZFS o exportar un iSCSI extent

Tipos de RAIDZ

  • Dynamic/Simple Stripe, es decir RAID0, distribuye los datos sin parity, y si se pierde un dispositivo se pierden todos los datos
  • MIRROR, es decir RAID1, replica los discos y se usa con 2 a 4 o más discos
  • RAIDZ-1, es decir RAID5, distribuye parity junto con los datos y puede tolerar la pérdida de 1 disco físico antes de una falla del RAID
    • RAIDZ requiere al menos 3 discos
  • RAIDZ-2, es decir RAID6, puede tolerar la pérdida de hasta 2 discos físicos
    • RAIDZ-2 requiere al menos 4 discos
  • RAIDZ-3 puede tolerar la pérdida de hasta 3 discos físicos
    • Requiere al menos 4 discos, aunque conviene no usarlo con menos de 5

Creación del pool y verificación de estado

  • Un pool de ZFS se crea con el formato zpool create [pool] [devices]
    • Ejemplo de pool con un solo disco: zpool create tank /dev/sdb
    • Ejemplo de stripe con 3 discos: zpool create tank /dev/sdb /dev/sdc /dev/sdd
    • Ejemplo de mirror con 2 discos: zpool create tank mirror sdb sdc
    • Ejemplo de pool RAIDZ: zpool create tank raidz sdb sdc sdd
    • RAIDZ2/3 puede crearse con el formato zpool create [pool name] raidz[1,2,3] [devices]
  • Al crear el pool, se puede definir el punto de montaje predeterminado con la bandera -m
    • Ejemplo: zpool create tank -m /mnt/tank mirror sdb sdc
  • En los ejemplos se usan nombres de dispositivo del tipo /dev/sdx, pero para evitar problemas de arranque causados por cambios en el nombre del dispositivo se prefiere usar la UUID del dispositivo
  • zpool status es el comando básico para verificar el estado del pool
    • state indica si el pool está en línea
    • status muestra información adicional sobre el pool
    • action muestra las acciones de seguimiento necesarias
    • scan muestra el avance del scrub o el estado del último scrub
    • errors indica si hay problemas en el pool
  • zpool list muestra detalles como tamaño del pool, asignación, espacio libre, fragmentation, capacity, dedup y health
  • zpool history muestra el historial de comandos usados para cambiar la configuración desde la creación del pool

Importar, exportar, eliminar y hacer scrub al pool

  • Después de crearse, un pool normalmente se importa y monta automáticamente, pero tras resolver problemas o reimaginar el sistema puede ser necesario importarlo manualmente
  • Si se ejecuta zpool import sin nombre de pool, muestra la lista de pools que pueden importarse
    • Si no hay pools disponibles, se muestra no pools available to import
    • Si se especifica el nombre del pool, se importa ese pool, y el comando de import también monta el pool
    • zpool import -a importa todos los pools disponibles
  • Si se usa -R, como en zpool import -R /mnt/tank2 tank, se monta en una ubicación de alternate root
    • Esto no es la ruta de montaje propia del pool, sino una carpeta root alternativa
  • zpool export [pool name] hace lo contrario de import: intenta exportar el pool después de desmontar los filesystem montados dentro de él
    • Si falla el desmontaje del filesystem, se puede forzar con -f
    • Si hay un ZFS volume en uso, la exportación falla incluso con -f
  • zpool destroy elimina el pool y sus dataset o volume hijos
    • Como también borra todos los datos y snapshots, hay que tener cuidado
  • ZFS scrub verifica la integridad de los datos comparando todos los bloques del pool con sus checksums conocidos
    • En vdev con parity, recupera datos dañados usando la información de los discos sanos
    • Para mantener la salud del sistema, conviene ejecutar scrub según una programación
    • Inicio: zpool scrub [pool]
    • Verificación de estado: revisar la sección scan de zpool status
    • Detener: zpool scrub -s [pool]

Creación de dataset y montaje

  • zfs create es el comando para crear un nuevo filesystem o volume, pero aquí se enfoca principalmente en dataset más que en volume
  • zfs create tank/dataset1 crea dataset1 debajo de tank
    • El dataset tank se crea automáticamente al ejecutar zpool create
  • zfs create -p también crea los dataset padre que no existan, como mkdir -p
    • Si no existe el dataset padre, zfs create normal falla
  • Si se ejecuta zfs mount sin argumentos, muestra los filesystem de ZFS montados actualmente y sus puntos de montaje
    • Esta salida no incluye los dataset hijos
  • zfs mount [pool|dataset] monta el filesystem especificado
    • zfs mount -a monta todos los filesystem
  • Un dataset hijo puede montarse incluso sin el dataset padre
    • En ese caso se crean las rutas necesarias en el filesystem del sistema operativo
    • Si luego se intenta montar el dataset padre, puede aparecer el error directory is not empty por los directorios creados
  • zfs unmount [dataset] desmonta el dataset especificado

Consulta de dataset y configuración de propiedades

  • zfs list [dataset name] muestra información del dataset especificado
    • También se puede pasar como argumento el punto de montaje en lugar del nombre del dataset
  • Si se ejecuta zfs list sin nombre de dataset, muestra recursivamente todos los dataset del sistema
  • Si se especifica un nombre de dataset, se puede usar la bandera -r para mostrar recursivamente lo que hay debajo de ese dataset
  • Las propiedades de ZFS controlan el comportamiento de filesystem, volume, snapshot y clone
    • Pueden parecerse a las opciones de montaje
  • zfs get all [dataset] muestra todas las propiedades del dataset
  • El valor de una propiedad específica puede consultarse con algo como zfs get compression tank
  • Para configurar propiedades se usa zfs set
    • Ejemplo: zfs set compression=lz4 tank
    • Después puede verificarse con zfs get compression tank que compression cambió a lz4

Funcionamiento y uso de los snapshots

  • Un snapshot guarda el estado de un filesystem en un momento específico, pero no copia los archivos
  • El snapshot marca los datos existentes como de solo lectura, y aunque después se agreguen nuevos datos al filesystem, eso no afecta los bloques de datos existentes que protege el snapshot
  • El flujo de ejemplo es el siguiente
    • Se crea el snapshot 1 en un filesystem que contiene los datos existentes Data A
    • Después se agrega Data B y se crea el snapshot 2
    • Después se agrega Data C
    • El snapshot 1 protege Data A, y el snapshot 2 protege Data A y Data B
    • Aunque se elimine el snapshot 1, Data A sigue protegido por el snapshot 2
  • La cantidad de datos que usa un snapshot es muy pequeña
    • Esto se debe a que, en lugar de copiar archivos, registra el bloque de metadata superior del filesystem que indica que pertenece al snapshot
  • Los snapshots son útiles para pruebas de desarrollo de software o para crear un failsafe antes de una actualización
  • Un snapshot por sí solo no debe considerarse una solución de backup o DR

Comandos de snapshot

  • Para crear un snapshot se usa el formato zfs snapshot [pool/dataset@snapshot_name]
    • Ejemplo: zfs snapshot tank/dataset1@snapshot1
  • La lista de snapshots se consulta con zfs list -t snapshot
  • Si hay varios dataset hijos, se puede crear un snapshot en el dataset de nivel superior o usar la bandera -r para crear un snapshot recursivo
    • Ejemplo de snapshot normal: zfs snapshot tank@snapshot-master
    • Ejemplo de snapshot recursivo: zfs snapshot -r tank@recursive
  • zfs diff [older snapshot] [newer snapshot] compara las diferencias entre snapshots
    • En la salida pueden verse archivos añadidos y rutas modificadas
  • La restauración de snapshots se hace con zfs rollback [pool/dataset@snapshot_name]
    • Al hacer rollback, se eliminan los archivos creados después del snapshot
    • También se eliminan los snapshots más recientes, y en ese caso puede pedirse usar la opción -r

ZFS send/recv y replicación

  • ZFS send permite enviar un snapshot como flujo de datos
  • Es posible replicar snapshots y dataset a un archivo, a otro pool o a otro sistema mediante SSH
  • El ejemplo usa dos pools llamados tank y backup
    • El dataset tank/Movies contiene 1.50G de datos
    • Antes de transferir, se crea un snapshot con zfs snapshot tank/Movies@$(date '+%Y-%m-%d_%H-%M')
    • zfs send tank/Movies@2020-11-03_15-29 | zfs recv backup/Movies envía el snapshot al pool de respaldo
  • Después de la transferencia, zfs list muestra tanto backup/Movies como tank/Movies, y zfs list -t snapshot también permite ver los snapshots en ambos lados
  • zfs send es una función que vale la pena explorar por sus múltiples opciones y casos de uso, y junto con RAIDZ y snapshots puede hacer más robusto el filesystem

Eliminación de dataset y snapshots

  • Para eliminar un dataset se usa el formato zfs destroy [pool/dataset]
    • También puede usarse la bandera -r
  • Para eliminar un snapshot también se usa zfs destroy [pool/dataset@snapshot_name]
    • La bandera -r también puede usarse al eliminar snapshots
  • ZFS ofrece muchas más funciones, pero este material está más cerca de ser un punto de partida para aprender los conceptos y comandos básicos

Material de referencia

Lecturas relacionadas

1 comentarios

 
GN⁺ 2023-09-06
Opiniones de Hacker News
  • Apenas estoy empezando con ZFS, y la curva de aprendizaje es más pronunciada de lo que esperaba. Me gustaría que hubiera un wrapper sencillo que simplificara mucho los casos de uso comunes.
    Por ejemplo, al crear un pool, que simplemente use valores predeterminados razonables como ashift=12, compresión lz4, xattr=sa, acltype=posixacl, atime=off, y que el cifrado solo tenga activar/desactivar en lugar de varias opciones.
    También estaría bien que generara la clave de cifrado, configurara un servicio de systemd para descifrar el pool al arrancar y guiara sobre cómo respaldar la clave. zfs list debería mostrar si el dataset está montado, si está cifrado y si la clave está cargada.
    Me gustaría que eliminaran los datasets recursivos y que, en lugar de {pool}/{dataset}, se usara {pool}:{dataset} para distinguir claramente pool y dataset. También estaría bien que uno no tuviera que nombrar pools ni snapshots directamente, sino que se asignaran automáticamente reglas como {hostname}-[A-Z], {pool name}_{datetime created} y nombres cortos numéricos.
    Al crear un pool, que no haya que ingresar manualmente el ID del disco; que se cree con /dev/sda, /dev/sdb y se guarden metadatos en el disco para que no haya confusión aunque se cambie el orden de las unidades.
    Que el progreso se muestre siempre con pv, y que se configuren automáticamente scrubs semanales, snapshots por hora/día/semana/mes y su limpieza.
    Si se envía a un disco sin pool, que tras pedir confirmación cree un pool de un solo disco con la misma configuración que el pool emisor, y que zpool y zfs se fusionen en un solo comando.
    Al enviar datasets cifrados, que use --raw automáticamente; que el valor predeterminado del envío sea --replicate, y que use -I si es posible. También hace falta una forma de montar y explorar fácilmente datasets de snapshots, en lugar de esconder el sistema de archivos de snapshots en un directorio oculto.
    • Hay una mezcla de propuestas razonables y gustos muy marcados. Entiendo el valor predeterminado ashift=12 o la sintaxis {pool}:{dataset}, pero parece difícil cambiarlos a estas alturas, y algunas propuestas podrían romper casos de uso que uno no conoce.
      Nombrar pools con el nombre del host no encaja con pools SAN que pueden importarse desde varios hosts.
      Creo que los scrubs semanales, los snapshots periódicos y las limpiezas periódicas son trabajo del scheduler del sistema operativo. Fusionar zpool y zfs también sería posible, pero al final terminaría siendo algo como zfs -pool XXXX, zfs -volume XXXX, y no veo por qué haría falta.
      Los datasets recursivos sí son útiles en algunos casos reales. En cambio, estoy totalmente de acuerdo en que zfs list debería mostrar si está montado, si está cifrado y si la clave está cargada.
      Lo de no ingresar IDs de disco es ambiguo. Se puede especificar de varias formas: ID, WWN, etiqueta, sdX, etc., pero de alguna manera hay que indicar qué disco se va a usar.
      La función de guardar metadatos en los discos para encontrarlos aunque cambien de orden ya existe. Si desconectas y vuelves a conectar varias unidades en otro orden e importas el pool, las encuentra.
      Algunas propuestas estarían bien como valores predeterminados, pero varias parecen no considerar lo suficiente patrones de uso y necesidades fuera de las propias. ZFS apunta a un público mucho más amplio.
    • Crear un pool con /dev/sda, /dev/sdb y que ZFS se confunda, sinceramente, se parece más a un problema del usuario por no usarlo de forma acorde a la época que a un problema de ZFS.
      En Linux existen desde hace bastante tiempo referencias completas como /dev/disk/by-id/ata-$manufactuer-$serial-$whatever. Al crear un pool hay que usar esas rutas.
    • Muchas propuestas dependen fuertemente del gusto personal; eso en sí no es malo, pero parece que sacuden convenciones existentes sin necesidad. Por ejemplo, no entiendo por qué tendría que ser {pool}:{dataset}.
      Si no quieres nombrar snapshots manualmente, puede servirte una pequeña herramienta que hice: https://github.com/rollcat/zfs-autosnap
      Si pones zfs-autosnap snap en cron cada hora y zfs-autosnap gc una vez al día, rota el historial de snapshots según la política de retención.
      No es difícil usar un wrapper de comandos de ZFS sencillo, así que puedes tomar mi código y hacer tu propia herramienta.
    • Leí alguna vez que una de las últimas tareas de un aprendiz de herrero era fabricar él mismo todas las herramientas que usaría un herrero real: yunque, martillos, tenazas, etc.
      En el trabajo también escribimos varios scripts para crear arreglos ZFS según la forma de despliegue prevista para ese día. Incluían crear volúmenes cifrados con LUKS sobre los que montar zvols, estandarizar reglas de nombres y configurar valores predeterminados como ashift=12 y compresión lz4.
      Esto fue mucho antes de que ZFS tuviera cifrado propio, y como el método actual no nos da problemas, no actualizamos los scripts para soportar cifrado de ZFS.
      Hoy ya no recuerdo muchas de las flags, pero los scripts sirven como documentación, y las demás personas del equipo solo tienen que ejecutar make-zfs-big-mirror o make-big-zfs-undundant-raid0.
      Si algún día surge la necesidad de aprovisionar sistemas más de 20 veces al año, incluso eso podría automatizarse mediante provisioning.
    • Como ya dijeron otros, son propuestas con gustos muy marcados. Está bien tener opiniones, pero muchos puntos van desde “no es la forma a la que estoy acostumbrado en Linux” hasta propuestas que sí tienen problemas reales.
      Decir que no se nombren los pools no tiene sentido. No se crean pools tan seguido, así que simplemente ponles un nombre.
      Si no quieres nombrar snapshots, puedes usar httm y zfs allow. Por ejemplo, httm -S . crea un snapshot como rpool/ROOT/ubuntu_tiebek@snap_2022-12-14-12:31:41_httmSnapFileMount.
      zfs y zpool son excelentes comandos Unix, cada uno con varios subcomandos. Creo que fue una decisión muy inteligente de los diseñadores de ZFS no crear un único comando de administración más complejo.
      Montar y explorar explícitamente datasets de snapshots también es fácil con zfs mount. Aun así, espero que crean que una interfaz virtual estable facilita la búsqueda en todas las versiones de archivos, y que eso es mucho más difícil en btrfs y otros. httm también vale como referencia.
      [0]: https://kimono-koans.github.io/opinionated-guide/#dynamic-sn...

  • Hay más cosas útiles en ZFS. Conviene conocer la diferencia entre zpool-attach(8) y zpool-replace(8), y zfs list -t all -o space muestra en qué se está usando el espacio
    Para proteger el sistema operativo antes de cambios grandes o actualizaciones, ZFS Boot Environments es la mejor función. Como punto de partida, https://is.gd/BECTL puede ser útil
    zpool history poolname muestra toda la configuración del pool y el historial de cambios. Por ejemplo, registra cambios como zpool create, autotrim=on, atime=off, compression=zstd, recordsize=1m
    También hay información importante que falta en la guía. Un mirror de 3 vías conserva los datos aunque fallen 2 de 3 discos; un mirror de 4 vías los conserva aunque fallen 3 de 4; y un mirror de N vías conserva los datos aunque fallen N-1 de N discos
    Es útil cuando los datos son lo más importante, pero no hay muchas ranuras o discos

    • Un mirror de N vías también tiene la característica de que ZFS puede repartir las lecturas entre varios discos. En discos giratorios, donde la cantidad de operaciones de E/S era limitada, esto era bastante importante

  • Desde hace años opero bases de datos PostgreSQL de gran tamaño, de varios TB, sobre ZFS. Gracias a ZFS, hacer backups, crear entornos de prueba basados en snapshots antiguos y ahorrar disco mediante compresión integrada se volvió muy fácil
    Si les interesa, pueden leer la experiencia en https://lackofimagination.org/2022/04/our-experience-with-po...

  • Lo que más me ayudó al empezar con ZFS fue el ZFS Handbook de FreeBSD y los artículos de Aaron Toponce
    [0] https://docs.freebsd.org/en/books/handbook/zfs/
    1 https://pthree.org/2012/04/17/install-zfs-on-debian-gnulinux...

    • Me gusta la documentación de FreeBSD
      Instalé FreeBSD en un HP Microserver viejo con 1 GB de RAM ECC que tenía por ahí, y como también tenía cinco discos duros viejos de 500 GB, lo configuré como mirror 5x siguiendo el FreeBSD Handbook. Era mi primera vez con FreeBSD y fue muy sencillo

  • Hace poco reconstruí gran parte de una infraestructura compuesta principalmente por servidores LAMP, y decidí dejar todo sobre ZFS en Linux para tener replicación de backups eficiente y cifrado
    Desde hace mucho usaba ZFS junto con rsync para backups, así que ya estaba bastante familiarizado y al final salió bien, pero hacerlo correctamente llevó mucho más tiempo del esperado. En particular, hay muchos malos consejos en la web sobre bases de datos y replicación
    Las bases de datos necesitan al menos ajustes básicos, como la alineación del tamaño de bloque. Para mariadb/InnoDB, el material de Let's Encrypt https://github.com/letsencrypt/openzfs-nvme-databases fue claramente el mejor. Es muy valioso porque justifica cada punto y cita varias fuentes
    Si uno busca más en la web, aparece una cantidad interminable de consejos contradictorios, anécdotas y mitos, mezclados con teorías incompletas y sin fundamento. Al final hay que probar por cuenta propia, entender qué se está ajustando, y también está bien decidir no ajustar algo
    Para la replicación, de verdad recomiendo las páginas del manual. ZFS ofrece herramientas de replicación robustas, pero son tan genéricas que se sienten como los comandos de plomería interna de Git. Como no asume que se va a usar por SSH, hay que conectarlo todo a mano, y si se quiere automatizar hay que pensar incluso en las condiciones de borde, así que al principio intimida
    Por eso todos terminan usando herramientas como syncoid, pero los scripts de replicación tipo syncoid tenían algo horrible: no usan el modo send --replication de ZFS, sino que lo reimplementan de forma incompleta en Perl con el argumento de que es más flexible
    Al hacer las primeras pruebas y restaurar desde cero, desespera ver que se rompen todas las raíces de cifrado y que no se sincronizan automáticamente todas las propiedades de los datasets. Si uno usa solo la opción de replicación recursiva integrada, ZFS se encarga de eso
    Si uno se decide a escribir su propio script, no es difícil. Basta con mantenerlo simple y no meter en el pipeline un montón de cosas innecesarias como hace syncoid. En pruebas reales, esas cosas incluso lo ralentizan. El progreso se puede ver con pv; simplemente se empuja y funciona rápido
    Quizás algún día publique mi script de replicación. Siento que casi no hay buenos scripts de referencia que cubran lo básico sin reimplementar mal la replicación

    • Ese material menciona el ajuste de io_capacity e io_capacity_max, pero si uno entra a la documentación de MySQL y ve qué hacen realmente esos parámetros, lamentablemente no son tan útiles
      Esos valores controlan la E/S en segundo plano, como la fusión del buffer de cambios, y pueden quitarle E/S al proceso principal que necesita hacer trabajo real
      Por mi experiencia operando una BD MySQL bastante ocupada, de 120K QPS, nunca fue necesario tocar ninguno de los dos. Si uno siente que hace falta, primero debería monitorear cuánto tarda en llenarse el redo log y la proporción de páginas sucias en el buffer pool. Probablemente convenga ajustar otros parámetros
      [0] https://dev.mysql.com/doc/refman/8.0/en/innodb-parameters.ht...
    • Al hacer ajustes básicos en bases de datos, como la alineación del tamaño de bloque, hay algo que conviene verificar y no es tan obvio. Normalmente se recomienda hacer coincidir el tamaño de registro, y en la práctica eso suele llevar a reducir el tamaño de registro del sistema de archivos ZFS que contiene los datos
      En cierto nivel puede ser más eficiente, pero por experiencia reduce mucho la tasa de compresión
      Como efecto secundario interesante, aunque depende de la carga de trabajo, si el ancho de banda del disco es el cuello de botella, el throughput puede incluso empeorar. Gracias a la compresión se puede leer y escribir más rápido de lo que soporta el disco físico; si se arruina la compresión, puede afectar negativamente el ancho de banda de lectura/escritura

  • Hace algunos años empecé a usar ZFS en Linux y, en general, todo fue bastante bien.
    Lo único que me sorprendió fue que el valor predeterminado de volblocksize es bastante malo para la mayoría de las configuraciones RAIDZ. Hay que aumentarlo si no se quiere perder el 50% del espacio bruto de disco.
    Estos son algunos artículos relacionados:
    https://jro.io/nas/#overhead
    https://openzfs.github.io/openzfs-docs/Basic%20Concepts/RAID...
    https://www.delphix.com/blog/zfs-raidz-stripe-width-or-how-i...
    Al final terminé viendo incluso una de esas hojas de cálculo sobre ZFS:
    ZFS overhead calc.xlsx
    https://docs.google.com/spreadsheets/d/1tf4qx1aMJp8Lo_R6gpT6...
    RAID-Z parity cost
    https://docs.google.com/spreadsheets/d/1pdu_X2tR4ztF6_HLtJ-D...

    • Personalmente, creo que la eficiencia del 50% de los vdev en espejo es un costo justo si se considera la simplicidad y la gran mejora de rendimiento. Hoy en día también se pueden expandir los pools RAIDZ, pero sigue siendo mucho más complejo y el rendimiento tampoco es tan bueno.

  • Cuando era más joven y más tonto, leí muchos textos de fanáticos entusiastas sobre lo increíble que era un sistema operativo NAS open source, probablemente FreeNAS, y ZFS. Compré en eBay un microservidor HP usado con especificaciones muy bajas y me lancé sin saber realmente qué estaba haciendo.
    Hice algunas preguntas en los foros de la comunidad, pero la mayoría de las respuestas eran “¿leíste la documentación?” y “¿tienes suficiente RAM?”.
    Esa “documentación” eran presentaciones de PowerPoint con un estilo difícil de leer, un tono algo evangelizador, muchos conocimientos dados por sentados y sin actualizaciones regulares. La cantidad de RAM necesaria también era ambigua, y el énfasis era simplemente ponerle la mayor cantidad posible.
    Al final ignoré todas las señales de alerta sobre la tecnología, el hype y mi nivel de conocimiento, y perdí muchos datos. Aprendí mucho.

    • Me da curiosidad si recuerdas más o menos hace cuánto fue. ZFS existe desde principios de los 2000, y creo recordar que FreeNAS empezó en 2005.
      El sistema de archivos se ha vuelto mucho más estable, y creo que la documentación también es más clara.
      Aun así, al ser más potente y avanzado que un sistema de archivos tradicional con journaling como ext3, también hay más formas de pegarse un tiro en el pie.

  • Para dejar algunas cosas más para el futuro: toda la redundancia de ZFS está en la capa de vdev. Un zpool se construye con uno o más vdev, y en cualquier caso, si se pierde un solo vdev dentro del zpool, el zpool queda destruido permanentemente.
    Históricamente, RAIDZ, es decir, RAID con paridad, no podía expandirse agregando discos. La única forma de hacer crecer RAIDZ era reemplazar cada disco del arreglo, uno por uno, por uno más grande, y esperar que ningún disco fallara durante la reconstrucción.
    En mi opinión muy amateur, solo consideraría RAIDZ en casos con muchos discos, como RAIDZ2 o RAIDZ3. Si n<=6 y el presupuesto lo permite, usaría varios vdev en espejo. En un entorno de producción habría que investigar más las métricas de rendimiento de lectura/escritura de los distintos RAID.

    • Un pool en espejo suele ser, efectivamente, el enfoque más seguro.
      Dicho eso, solo recomendaría RAIDZ1 si hay un backup completo en el mismo sitio y si puedes confiar bastante en tus habilidades y en tu monitoreo.
      En mi caso tengo un pool de 3x3 discos y envío snapshots a un destino de backup unos cuantos U más abajo en el rack. Ese destino de backup se despierta todos los días, tiene un pool de 3x4 discos y también usa RAIDZ1.
      Si falla un disco en el NAS, mi plan es iniciar de inmediato el backup, recibir los snapshots y luego reemplazar el disco. Así se puede minimizar la posibilidad de perder datos por una segunda falla de disco durante el resilvering.
      Los datos realmente importantes, por supuesto, también los mantengo fuera del sitio.

  • Estoy teniendo un problema con ZFS que no entiendo. En cierto zpool, zpool status muestra una lista de errores detectados, pero no aparecen en archivos: siempre aparecen solo en snapshots y quizá en entradas hexadecimales que parecen snapshots eliminados.
    Si elimino los snapshots marcados con error y ejecuto zpool scrub dos veces, los errores desaparecen y el scrub tampoco encuentra errores. zpool status nunca ha mostrado errores en ningún dispositivo.
    No hay errores en archivos, no hay errores en los dispositivos y el scrub no detecta errores, pero mientras está en ejecución aparecen en zpool status unos 12 “errores” nuevos por día. No entiendo cómo puede pasar algo así.

    • Es una muy buena pregunta. Ahora no tengo tiempo para buscar directamente problemas duplicados, pero puedes revisar o preguntar en la mailing list https://zfsonlinux.topicbox.com/groups/zfs-discuss y en los issues de GitHub https://github.com/openzfs/zfs/issues.
      La primera se ve rara, pero es el frontend web normal de la mailing list.
    • Estoy teniendo el mismo problema. A veces un archivo parece estar dañado no solo en el snapshot, sino también en la versión actual del archivo.
      No se puede mover ni modificar, solo borrar. No tengo ninguna pista de por qué se dañan esos archivos. Por suerte todos eran ISO grandes de Linux, así que no fue crítico.