Btrfs/ZFS/bcachefs bajo cargas de trabajo: benchmarks clásicos omitidos

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

Un nuevo conjunto de benchmarks que compara sistemas de archivos modernos copy‑on‑write como ZFS, Btrfs y bcachefs bajo cargas de trabajo de múltiples dispositivos ha despertado interés por su enfoque en la integridad de datos, pero también escepticismo por usar VMs ruidosas alojadas en GitHub en lugar de hardware dedicado. Los comentaristas cuestionan cuán realistas son las pruebas (por ejemplo, scrubs tras corrupción deliberada de bloques, eludir la caché de páginas, métricas de latencia personalizadas) y sugieren más escenarios, hardware y una presentación de datos más clara. Gran parte del debate gira en torno a las compensaciones entre rendimiento, fiabilidad y soporte a largo plazo, incluidas las preocupaciones por la retirada de bcachefs del Linux mainline, los problemas pendientes de RAID‑5/6 y robustez de Btrfs, y las restricciones de licencia y empaquetado de ZFS en las distribuciones de Linux.

Alcance y metodología de los benchmarks

  • Los benchmarks se centran en sistemas de archivos CoW de múltiples dispositivos y configuraciones tipo RAID (incluido el comportamiento de integridad / scrub), usando fio para medir rendimiento, IOPS y latencia de fsync.
  • Varias cargas de trabajo son personalizadas (por ejemplo, una escritura de 4 KiB + fsync cada 200 ms como sonda de latencia de una “operación trivial”). Se reconoce que son específicas del proyecto, no estándares de la industria.
  • Las pruebas se ejecutan actualmente en su mayoría en VMs alojadas en GitHub, con archivos dispersos respaldados por bucles; el autor insiste en que solo deben compararse las “formas y proporciones” relativas, no los MB/s absolutos.
  • Hay un paso de calibración para descartar las VMs más ruidosas, y existen algunas ejecuciones limitadas en “hardware real”, con más en curso, incluidas configuraciones híbridas HDD/SSD y por niveles.

Pruebas de integridad de datos y corrupción

  • Una prueba sobrescribe 2 GiB de bloques brutos en un único dispositivo dentro de un conjunto replicado, y luego ejecuta scrubs del sistema de archivos.
  • Algunos comentaristas cuestionan si eso es realmente “recuperable” y qué significa en realidad que la “integridad” tenga éxito o falle.
  • El autor aclara que la etiqueta se renombrará a “sonda de corrupción”: “sobrevivió” solo significa que un archivo específico siguió siendo legible y sin cambios, no que todo el sistema de archivos esté completamente sano.

Presentación y usabilidad de los resultados

  • Varias personas encuentran la página densa y visualmente difícil de recorrer: texto pequeño, demasiadas gráficas a la vez, definiciones poco claras para puntuaciones compuestas como “Overall Core” y “Core I/O”.
  • Otros, especialmente ingenieros, aprecian la “pared de datos” y prefieren el detalle frente a la simplificación.
  • Las sugerencias incluyen descripciones más claras de lo que se está probando, mejores explicaciones para las métricas derivadas, mover los metadatos de la ejecución lejos de la parte superior y, posiblemente, vistas “simplificadas” alternativas usando los datos JSON.

Realismo del entorno y cobertura de hardware

  • Algunos sostienen que los runners compartidos en la nube con vecinos ruidosos hacen que los resultados sean difíciles de fiar, y abogan por bancos de pruebas dedicados bare-metal.
  • Otros aceptan las limitaciones, señalando el enfoque en la integridad más que en el rendimiento absoluto y la dificultad/coste de una automatización extensa sobre bare-metal.
  • Aparecen múltiples peticiones de más escenarios: HDD frente a SSD, NVMe, distintos tamaños de RAID, sistemas de archivos no CoW, dm-integrity, dRAID, F2FS, DRBD, CephFS y XFS con capas de integridad.

Bcachefs, Btrfs, ZFS y alternativas

  • Bcachefs muestra resultados sólidos en los benchmarks y es elogiado por funciones como mezclar niveles de dispositivos y replicación por archivo, pero persisten dudas sobre su madurez y su reciente eliminación del mainline.
  • A algunos usuarios les va bien bcachefs vía out-of-tree/DKMS en ciertas distribuciones (por ejemplo, entornos basados en NixOS, appliances NAS), citando buena experiencia práctica.
  • Btrfs se ve como la opción “moderna por defecto” en árbol, pero se critica por:
    • Falta de informes fiables de espacio libre.
    • Comportamiento frágil cuando los volúmenes se llenan.
    • Herramientas de reparación débiles y RAID5/6 todavía no recomendado.
    • Bloqueos ocasionalmente severos al borrar archivos muy grandes en algunos entornos.
  • ZFS goza de gran confianza para la seguridad de los datos, pero se critica por:
    • Menor rendimiento en algunas cargas de trabajo.
    • Fricción de licencias que lo mantiene fuera de muchas distribuciones y entornos de rescate.
    • DKMS quedándose atrás frente a actualizaciones rápidas del kernel en algunas distros.
  • Muchos comentaristas orientados a producción siguen prefiriendo pilas más simples como ext4/XFS sobre LVM/MD RAID por su previsibilidad, a veces complementadas con capas separadas de compresión/deduplicación (por ejemplo, dm-vdo).

Factores sociales y gobernanza del kernel

  • Varios comentarios subrayan que la “salud social” de un sistema de archivos (bus factor, drama del mantenedor, problemas de CoC, patrocinio corporativo) importa tanto como el rendimiento bruto.
  • La retirada de bcachefs del mainline y conflictos previos con mantenedores del kernel generan preocupaciones de confianza y estabilidad futura para algunos; otros sostienen que estos son sobre todo problemas del mantenedor y que los usuarios finales solo necesitan buenas herramientas y fiabilidad.
  • Hay un interés amplio en que bcachefs vuelva eventualmente al mainline una vez que el desarrollo se estabilice y exista un equipo de mantenedores más amplio.