¿Un error de corrupción de datos en OpenZFS?

Artículo original ↗ Discusión en Hacker News ↗

Una rara condición de carrera en OpenZFS puede hacer que archivos se llenen silenciosamente de ceros durante ciertas operaciones de copia, sin que los scrubs detecten la corrupción tradicional, lo que genera preocupación entre quienes dependen de ZFS para la integridad de los datos. Los comentaristas subrayan que el error es difícil de provocar y probablemente no ha afectado a la mayoría de los sistemas, pero lo usan como punto de partida para insistir en estrategias de copia de seguridad robustas y probadas, almacenamiento selectivo fuera del sitio y conciencia de cómo funciones como los archivos dispersos y las instantáneas interactúan con cargas de trabajo reales. El hilo también aborda alternativas como bcachefs, las limitaciones de los modos RAID de Btrfs y el impacto de las licencias y de la gestión de Oracle en la adopción de ZFS en Linux.

Impacto del error de OpenZFS

  • Se describe como una condición de carrera muy rara, difícil de provocar en la práctica.
  • Los síntomas serían evidentes en cargas de trabajo intensivas de escritura/movimiento (por ejemplo, árboles de compilación que de repente contienen archivos llenos de ceros).
  • Se señala que comprobar bcloneused/bclonesaved no es una prueba fiable; los bclones eran solo uno de los desencadenantes.
  • La corrupción no es el daño tradicional en disco: cp lee ceros y los escribe, y ZFS los almacena correctamente, así que los scrubs y las comparaciones byte a byte con copias de seguridad no lo detectarán.
  • Dada la antigüedad del error y la falta de informes de grandes usuarios de ZFS, varios comentarios sostienen que el riesgo en el mundo real es bajo.

Fiabilidad y pruebas de las copias de seguridad

  • Se hace mucho hincapié en que las copias de seguridad a menudo fallan de forma frecuente y silenciosa: las herramientas pueden saltarse archivos, detenerse a mitad de ejecución o registrar mal los errores.
  • Recomendación:
    • Probar las restauraciones con regularidad, incluidas las de sistemas que rara vez tocas.
    • Hacer que alguien distinto al experto realice las restauraciones, para validar la documentación y las herramientas.
    • Mantener actualizados los scripts y las herramientas de reparación.
    • Verificar las copias de seguridad después de ejecutarlas (tamaños, capacidad de descifrar/desempaquetar, hashes cuando sea posible).
    • Usar al menos dos implementaciones de copia de seguridad diferentes.
  • Las copias de seguridad de bases de datos se destacan como especialmente delicadas; las instantáneas del sistema de archivos por sí solas no son suficientes para la consistencia transaccional.

NAS doméstico y estrategias de copia de seguridad de grandes volúmenes de datos

  • Muchos sostienen que “NAS doméstico promedio” no significa 40 TB; para la mayoría, solo un subconjunto (fotos, documentos) necesita copia de seguridad en la nube.
  • Estrategias mencionadas:
    • Nube (Backblaze, S3 Glacier/Deep Archive, Hetzner Storagebox, B2) con niveles según la importancia.
    • Un segundo NAS o servidor fuera del sitio (familia/amigos) usando rsync/ZFS send/syncthing sobre VPN/Tailscale/Nebula.
    • Almacenamiento en frío en HDD/SSD externos, rotados y mayormente desconectados.
    • Cinta LTO para conjuntos de datos grandes y críticos, que algunos describen como rentable a largo plazo pero operativamente tediosa y ruidosa.
  • Reglas generales: invertir ~3× el coste de tu almacenamiento “caliente” en copias de seguridad; priorizar varias copias no redundantes frente a una sola copia con RAID.

Archivos dispersos y abstracciones del sistema de archivos

  • Debate sobre si los archivos dispersos y SEEK_HOLE/SEEK_DATA fueron un error de diseño o una optimización útil.
  • Algunos ven los archivos dispersos como una filtración de detalles de nivel de bloque al espacio de usuario y una complejidad añadida que puede causar errores como este.
  • Otros argumentan que son esenciales para cargas de trabajo como torrents, bases de datos, imágenes de VM y desduplicación.
  • Discusión sobre fallocate, mmap y cómo distintos sistemas de archivos y la semántica COW interactúan con la preasignación y la fragmentación.

Sistemas de archivos alternativos y política de licencias

  • Se señala que errores recientes que bloquearon todo estaban en OpenZFS, no en el ZFS cerrado de Oracle, pero Oracle prácticamente abandonó Solaris.
  • Larga discusión sobre CDDL frente a GPL: la incompatibilidad complica integrar OpenZFS en Linux; algunos sostienen que el riesgo legal está exagerado, otros ven a Oracle como una amenaza seria.
  • Se cita el envío de ZFS por parte de Ubuntu durante años sin acción legal, pero algunos creen que futuras demandas siguen siendo posibles.
  • Algunos ven bcachefs como una alternativa prometedora nativa de Linux (discos heterogéneos, redundancia estilo RAID-5/6, compatible con SMR), pero otros advierten que aún es joven, con exposición limitada en el mundo real y reportes de corrupción.