Lanzan ZFS 2.3, con expansión RAIDZ incluida

 (github.com/openzfs)
1 puntos por GN⁺ 2025-01-15 | 1 comentarios | Compartir por WhatsApp
  • OpenZFS 2.3.0 incluye como función principal RAIDZ Expansion, que permite agregar nuevos dispositivos a un pool RAIDZ existente para aumentar la capacidad sin tiempo de inactividad
  • Fast Dedup mejora notablemente el rendimiento de la función de deduplicación existente, junto con mejoras de rendimiento en toda la base de código
  • Direct IO permite omitir el ARC en lecturas/escrituras, apuntando a entornos donde el caché puede reducir la eficiencia, como con dispositivos NVMe
  • Se agregan salida JSON opcional para comandos de uso frecuente, soporte para nombres de archivos y directorios de hasta 1023 caracteres, y correcciones importantes de bugs que abordan problemas de versiones anteriores
  • El soporte abarca kernels Linux 4.18 a 6.12 y FreeBSD 13.3, 14.0 a 14.2; en este ciclo de lanzamiento participaron 134 personas

Qué cambió en OpenZFS 2.3.0

  • OpenZFS 2.3.0 se actualiza con foco en la expansión de almacenamiento, el rendimiento de deduplicación, la ruta de E/S, el formato de salida de comandos y el soporte de longitud de nombres de archivo
  • La etiqueta de lanzamiento es zfs-2.3.0 e incluye cambios desde OpenZFS 2.2.0

Expansión de almacenamiento y mejoras de rendimiento

  • RAIDZ Expansion permite agregar un nuevo dispositivo a un pool RAIDZ existente para aumentar la capacidad de almacenamiento sin tiempo de inactividad
  • Fast Dedup es una mejora importante de rendimiento para la función de deduplicación existente de OpenZFS
  • Direct IO permite omitir el ARC en lecturas/escrituras
    • Busca mejorar el rendimiento en situaciones donde el caché puede interferir con la eficiencia, como en dispositivos NVMe
  • También se incluyen varias mejoras de rendimiento en toda la base de código

Salida de comandos y longitud de nombres

  • JSON agrega salida JSON opcional a los comandos más usados
  • Long names admite nombres de archivos y directorios de hasta 1023 caracteres

Estabilidad, plataformas y contribuciones

  • Incluye correcciones importantes de bugs que abordan problemas reportados en versiones anteriores
  • Plataformas soportadas:
    • Kernels Linux 4.18 a 6.12
    • FreeBSD 13.3, 14.0 a 14.2
  • En este ciclo de lanzamiento participaron 134 contribuidores

Documentación y registro de cambios

Cambios en opciones de módulos

  • La lista completa de opciones y los elementos que controlan está organizada en la documentación de parámetros de módulos
  • Las nuevas opciones de módulos incluyen elementos relacionados con expansión RAIDZ, registro de deduplicación, Direct IO, allocator, scrub y resilver
    • Ej.: raidz_expand_max_copy_bytes, raidz_expand_max_reflow_bytes, zfs_dio_enabled, zfs_dedup_log_mem_max, zfs_scrub_after_expand
  • Opción de módulo eliminada:
    • zfetch_array_rd_sz
  • Opciones de módulos modificadas:
    • zfs_arc_shrinker_limit
    • zfs_bclone_enabled
    • zfs_vdev_disk_classic
    • zio_taskq_write

Lecturas relacionadas

1 comentarios

 
GN⁺ 2025-01-15
Opiniones de Hacker News

  • La expansión de ZFS RAIDZ, preparada durante años, por fin llegó
    Las funciones principales son la expansión RAIDZ, que permite agregar dispositivos a un pool RAIDZ existente para aumentar la capacidad sin interrupciones; la deduplicación rápida, que mejora mucho el rendimiento de la deduplicación de OpenZFS; la E/S directa, que mejora el rendimiento en entornos donde la caché puede ser ineficiente, como con NVMe, al omitir el ARC; salida JSON opcional para comandos de uso frecuente; y compatibilidad con nombres de archivos y directorios de hasta 1023 caracteres

    • Más precisamente, significa que se puede agregar un dispositivo nuevo, es decir, un disco, a un vdev RAIDZ existente
    • Si estás corriendo Proxmox sobre ZFS y NVMe, me pregunto si conviene activar la E/S directa cuando se distribuya la versión 2.3
      Quisiera saber para qué tipo de uso está pensada esta función
    • Las primeras cuatro parecen cambios realmente importantes
    • Aun así, parece que la eliminación de vdev todavía no es posible
    • Me pregunto qué tan bien se probó esta función junto con el cifrado
      También me pregunto si el equipo de ZFS realmente trata el cifrado como una prioridad de primer nivel
      ZFS en Linux heredó gran parte de la reputación de ZFS en Solaris, pero quienes lo usan en entornos de producción tienen que mirar bastante de cerca el issue tracker para ver la realidad

  • No entiendo que Windows, por lejos la plataforma de PC más grande por cantidad de usuarios, todavía no tenga una respuesta a ZFS
    Microsoft tuvo WinFS y luego ReFS, pero quedaron relegados; aunque el desarrollo continúa y de vez en cuando algunas partes llegan a Win11, no se ve un lanzamiento formal
    Algunas personas están intentando el enorme trabajo de crear una capa de compatibilidad con ZFS, pero todavía está lejos de ser madura o usable en la práctica
    No sé cómo Windows sigue usando un sistema de archivos de 32 años

    • Sinceramente, la situación de Linux tampoco es mucho mejor
      ZFS tiene problemas de licencia con Linux que impiden una integración completa, y Btrfs lleva 15 años en desarrollo pero todavía no alcanza a ZFS en funciones y estabilidad
      La mayoría de las distribuciones Linux siguen usando por defecto ext4, de 19 años, que en realidad es más bien una extensión montada sobre ext2, de la misma edad que NTFS
      Para ser justos, pocos componentes de un sistema operativo son tan importantes como el sistema de archivos, y mucha gente prefiere no tocar un sistema de archivos que no haya sido probado durante más de 10 años en producción
    • La razón es simple. La mayor parte de la carga que debería asumir el sistema de archivos la asume el hardware de almacenamiento empresarial sobre el que se coloca ese sistema de archivos
      El equipo de almacenamiento se encarga de las funciones necesarias, como snapshots, deduplicación a nivel de bloque, tecnologías de almacenamiento de objetos, RAID/resiliencia, redimensionamiento, etc.
      Los appliances de almacenamiento modernos son casi magia negra, así que NTFS no necesita necesariamente más funciones
      Basta con acceder de forma transparente mediante NAS/SAN, o almacenar volúmenes NTFS sobre una caja de discos competente
      En el segmento avanzado del mundo Linux están Lustre y GPFS, y ZFS suele encajar en usos donde el rendimiento no es lo principal, pero sí se necesita resiliencia
    • En el kernel mainline de Linux tampoco hay una respuesta equivalente a ZFS
      Creo que es porque es difícil y de alto riesgo, mientras que la recompensa suele limitarse al respeto técnico
    • Como usuario final que usa Windows y Linux pero no ZFS, me pregunto qué me estoy perdiendo
    • OpenZFS para Windows ya llegó al estado de release candidate (rc11), y quedan algunos bugs alrededor del montaje de volúmenes
      No son graves, pero por ahora conviene evitar el cifrado, y el ritmo de desarrollo es tan rápido que salen nuevos release candidates cada pocas semanas para corregir los problemas restantes
      Si se combina esto con Storage Spaces para agrupar discos de distintos tipos o tamaños y definir ubicación, redundancia y tiering por Space, Windows se convierte ahora en una plataforma de almacenamiento avanzada
      Si usas Windows Server, por ejemplo las económicas ediciones 2022/2025 Essentials, también puedes usar SMB Direct/RDMA con rendimiento de hasta 10 Gbyte/s en la LAN y sobre discos duros virtuales .vhdx, lo que lo vuelve una alternativa más rápida y sin configuración frente a iSCSI
      Por eso porté napp-it cs, una GUI web para ZFS, de Solaris a Windows, para administrar Storage Spaces, ZFS y servidores OpenZFS remotos como Proxmox; es gratis para uso no comercial

  • Me gusta que hayan hecho la función de expansión de forma bastante conservadora
    La expansión no solo es completamente transparente y reanudable, sino que además mantiene la redundancia durante todo el proceso
    Pero hay un pequeño detalle que la gente debería tener en cuenta
    Incluso después de terminar la expansión, los bloques existentes conservan la relación anterior entre datos y paridad. Por ejemplo, un RAIDZ2 de 5 discos se distribuye en un conjunto más grande de discos manteniendo 3 datos por 2 paridades
    Los bloques nuevos se escriben con la nueva relación entre datos y paridad. Por ejemplo, si un RAIDZ2 de 5 discos se expande una vez y pasa a 6 discos, queda en 4 datos por 2 paridades

    • No estoy tan seguro de que eso sea realmente un detalle importante. Solo significa que los datos existentes pueden quedar con una distribución no óptima
      Aun así, las ventajas de RAIDZ N se mantienen: el pool sigue funcionando aunque fallen por completo hasta N discos
    • Ese detalle es un comportamiento bastante previsible. En general, hay que asumir que las funciones de ZFS no reescriben los bloques existentes
      Por ejemplo, los cambios de configuración también se aplican solo a los datos nuevos
    • Sinceramente, es un detalle bastante grande
      Da1 Db1 Dc1 Pa1 Pb1
      Da2 Db2 Dc2 Pa2 Pb2
      Da3 Db3 Dc3 Pa3 Pb3
      ___ ___ ___ Pa4 Pb4
      Aquí ___ es espacio vacío. Si se agrega un disco y se expande, lógicamente uno podría esperar algo como esto
      Da1 Db1 Dc1 Da2 Pa1 Pb1
      Db2 Dc2 Da3 Db3 Pa2 Pb2
      Dc3 ___ ___ ___ Pa3 Pb3
      ___ ___ ___ ___ Pa4 Pb4
      Pero, según entiendo, en realidad se expande así
      Da1 Db1 Dc1 Dd1 Pa1 Pb1
      Da2 Db2 Dc2 Dd2 Pa2 Pb2
      Da3 Db3 Dc3 Dd3 Pa3 Pb3
      ___ ___ ___ ___ Pa4 Pb4
      Aquí los bloques Dd1~3 simplemente se desperdician. Es decir, aunque agregues un disco nuevo al arreglo, el espacio libre solo aumenta un 25%
      Por ejemplo, si originalmente tenías 24 TB de espacio utilizable total con discos de 8 TB y antes de expandir había 4 TB libres, después de expandir habrá 5 TB libres
      Ojalá me digan que lo entendí mal. Si no lo entendí mal, parece una implementación bastante inútil

  • Es una gran noticia para los usuarios de ZFS. Probablemente sobre todo para usuarios aficionados y domésticos, pero sigue siendo importante
    La expansión de RAIDZ fue una de las funciones más solicitadas durante años

    • Todavía no estoy familiarizado con ZFS y tampoco lo encontré en las notas de la versión, pero me pregunto si la expansión solo funciona con discos del mismo tamaño
      Quisiera saber si se pueden agregar discos más grandes o más pequeños, o si todos los discos deben tener el mismo tamaño

  • Esto es expansión en línea. La expansión en sí ya era posible antes, pero había que bajar el arreglo
    También era posible migrar a unidades más grandes, pero había que reemplazarlas de a una, y por supuesto solo se obtenía la nueva capacidad después de actualizar todas las unidades
    Hasta donde sé, reducir un pool todavía no es posible. Así que si agregas un sexto disco a un pool de 5 discos, no puedes volver a 5 aunque tengas muy pocos datos

  • ¡Por fin!
    Ahora también se vuelve posible una configuración de vdev único al borde de la locura, como RAID-Z3 con 4 de los discos duros más caros y de mayor densidad que se puedan comprar hoy
    Al principio, con redundancia equivalente a 3 discos, el uso efectivo del espacio es de apenas 25%, pero a medida que aumente la demanda de espacio se puede comprar un disco por vez y expandir hasta alrededor de 12 discos
    Con el tiempo los precios de los discos bajan, y como los discos se agregan en distintos momentos, también se distribuye la probabilidad de fallas

    • Correcto, pero también hay que ver el comentario hermano
      Aunque expandas el arreglo, los datos existentes no se almacenan de forma más eficiente
      Para obtener la nueva relación paridad/datos, tendrías que forzar la copia de los datos y borrar la versión antigua e ineficiente. Por ejemplo, haría falta una herramienta como esta [1]
      Personalmente, creo que es mucho mejor comprar configuraciones RAID-Z completas por separado y agregar una nueva configuración, o ir reemplazando la configuración antigua disco por disco
      [1] https://github.com/markusressel/zfs-inplace-rebalancing

  • Me da curiosidad saber cómo se compara ZFS con btrfs
    Actualmente uso btrfs en mi servidor doméstico, pero ya me encontré varias veces con problemas raros
    Estoy pensando en pasarme a ZFS, pero no quiero terminar en la misma situación

    • Probé btrfs por primera vez hace 15 años, alrededor de Linux 2.6.33-rc4
      A los 3 días apareció un archivo que no podía borrar, así que dejé de usarlo y más tarde encontré ZFS
      ZFS también tenía algunos problemas menos graves, pero en ese entonces yo era estudiante de ciencias de la computación y, comparados con los problemas que tuve con btrfs, me parecían menores, así que pensé que podría corregirlos
      Durante los siguientes 18 meses resolví todos los problemas que me molestaban y envié parches al repositorio de ZFSOnLinux de la época; ese esfuerzo ayudó a que ZFS pudiera usarse en entornos de producción en Linux
      Desde entonces seguí usando ZFS y ha funcionado bien
      Si el estado de btrfs hubiera sido mejor, me habría convertido en colaborador de btrfs. Pero no solo su estado era malo en ese momento; incluso después, cada vez que intentaba usarlo para algo serio, seguían apareciendo problemas que me frenaban, como ENOSPC frecuente aunque todavía hubiera espacio
      En cambio, ZFS simplemente funciona. Yo y muchas otras personas trabajamos mucho para que funcionara bien
      La mayor diferencia es que ZFS tenía una base muy sólida, gracias a una excelente infraestructura de pruebas de regresión
      Una versión en espacio de usuario ejecuta el código de forma aleatoria para encontrar bugs antes de que exploten en producción, y se corre un conjunto de pruebas para cada cambio propuesto para filtrar errores
      ZFS también tiene más personas revisando los cambios propuestos que otros sistemas de archivos. Los desarrolladores de Btrfs suelen decir que hay una gran diferencia de personal entre ambos sistemas de archivos; recuerdo que hablaban de una diferencia de unas 6 veces
      En cualquier caso, es raro que alguien se arrepienta de usar ZFS, así que probablemente te guste
    • ZFS se ha usado en entornos de producción durante casi 20 años
      Según la documentación de BTRFS, BTRFS todavía no es completamente apto para producción: https://btrfs.readthedocs.io/en/latest/btrfs-man5.html#raid5...
      Algunos casos de uso simples pueden considerarse suficientemente aptos para producción con BTRFS, pero los resultados varían según el entorno
    • btrfs tiene objetivos similares a ZFS, pero es mucho menos maduro
      Lo usé en la partición raíz porque no requiere DKMS, pero tuve muchos problemas
      Lo usaba de forma bastante simple, solo en espejo, pero un día, cuando una de las unidades del arreglo tuvo un problema, btrfs no aguantó correctamente
      Si mal no recuerdo, volvió a montar todo en modo de solo lectura y, por defecto, no funcionó en modo degradado
      Incluso mdraid, que no tiene funciones como checksums, habría sido mejor que eso
      ZFS también marca el arreglo como defectuoso, pero por supuesto permite seguir usándolo
      Perdí la confianza porque el comportamiento predeterminado no era el de un RAID; es decir, en la práctica faltaba la parte de la R, la de volver a leer los datos
      Desde que me pasé a ZFS no he tenido problemas, y además hay una comunidad y buenas herramientas mucho más amplias
    • Usé Btrfs durante varios años y lo dejé hace algunos años
      También me pasaron una o dos cosas raras con Btrfs, pero al final pude recuperarlo todo
      En general me gustaba la flexibilidad de Btrfs, pero en la mayoría de los casos me parecía demasiado lento
      Ahora uso ZFS en Arch Linux y, hasta ahora, en general no he tenido problemas
      También hay más ajustes y métodos para optimizar el rendimiento
      Si tuviera que dar un consejo, diría que conviene investigar y probar lo suficiente con ZFS. Tiene una pequeña curva de aprendizaje, pero para mí valió la pena el cambio

  • Me alegra que ahora exista el bypass de ARC para el rendimiento de NVMe
    ZFS suele no aprovechar bien el potencial de NVMe
    La expansión en línea también podría ser interesante
    Intenté usar ZFS en una base de datos muy ocupada y me golpeó fuerte un bug de fragmentación
    La única forma de recuperar el rendimiento parecía ser copiar los datos fuera del volumen, destruir el volumen y volver a copiarlos
    Ahora quizá sea posible expandir el zpool y luego copiar el tablespace dentro del mismo volumen para reducir la fragmentación

  • También vale la pena notar que TrueNAS ya soporta esta función[0]
    Parece que probablemente usa 2.3.0rc3; no sé qué tan estable será, pero me entusiasma mucho
    https://www.truenas.com/blog/electric-eel-openzfs-23/

  • ¿Alguien puede explicar por qué usaría algo como ZFS en casa?

    • Para mí, las ventajas son estas:
      Suma de verificación: en un entorno doméstico normalmente el hardware es de menor calidad, así que es aún más importante. Hay muchas razones por las que podrían guardarse datos incorrectos: controladores defectuosos, cables pésimos, discos duros mantenidos a temperaturas más altas que las recomendadas, etc. Si hay redundancia, ZFS maneja esto muy bien automáticamente.
      Snapshots: son muy útiles para hacer backups y volver rápidamente a una versión anterior de un archivo cuando te equivocas.
      Tranquilidad: comparado con las alternativas, siento que ZFS es fácil de usar y que es difícil cometer errores que terminen en pérdida de datos. Por ejemplo, si al reemplazar una unidad fallada sacas por error la unidad equivocada y el pool queda inutilizable, al volver a conectarla todo regresa como si nada hubiera pasado.
      Puede que mdadm ahora sea distinto, pero cuando lo usé hace unos años siempre me ponía nervioso cometer un error destructivo.
    • Por dar una respuesta que otros no dieron: ZFS es bueno para guardar juegos de Steam.
      Si configuras recordsize=1M y compression=zstd, muchas veces puedes guardar alrededor de 33% más juegos en el mismo espacio.
      Un amigo usa ZFS para guardar juegos de Steam en varios discos duros. Además, le asignó a ZFS un SSD como L2ARC.
      ZFS cachea automáticamente en el SSD los juegos que ejecuta con frecuencia, para que carguen rápido.
      Si cambian tus juegos favoritos, ZFS se adapta automáticamente y cachea esos juegos en el SSD.
    • Uso zrepl para replicar todo el sistema de archivos a un NAS local cada 10 minutos.
      Ya me salvó una vez cuando un WD_BLACK SN850 murió de repente [1].
      También me recuperó código que había perdido por el clásico error con git.
      Perder datos por un error del usuario o por la falla de un solo dispositivo ya no debería ser posible. Tenemos la tecnología para eso.
      [1]: https://chromakode.com/post/zfs-recovery-with-zrepl/
    • Hay varias razones, pero para mí las grandes son la confiabilidad y la portabilidad.
      No hay otro sistema de archivos moderno con sumas de verificación y autorreparación que se pueda leer y escribir en Linux, FreeBSD, Windows y macOS.
      Btrfs también soporta snapshots, es decir, entornos de arranque. Mi instalación de Linux lo usa para no tener que preocuparme por un módulo de kernel de terceros para leer el sistema de archivos raíz.
      El rendimiento tampoco es excelente y, si en Linux tu prioridad principal es el rendimiento, XFS es una mejor opción.
    • Es relativamente fácil, pero potente.
      Antes usaba MDADM + LVM + dm-crypt + ext4, y también funcionaba, pero eran demasiadas capas y era un dolor de cabeza.
      Los snapshots automáticos son muy fáciles y rápidos.
      También es fácil acceder a ellos cuando borras un archivo: no hace falta restaurar todo el snapshot; simplemente puedes hacer cp desde la carpeta oculta .zfs/.
      Llevo años usándolo con 6 discos de 8 TB. Es RAIDZ2, así que pueden morir hasta 2 discos.
      Si me preguntas si lo usaría en un solo disco de escritorio, probablemente no.