Caza de bugs en Btrfs

Futuro de Btrfs frente a ZFS/Bcachefs

• Algunos esperan que Btrfs tenga un largo futuro, especialmente dadas las complicaciones de licencia de ZFS y la inmadurez de funciones de Bcachefs como la codificación de borrado y el scrub.
• Otros creen que Bcachefs acabará reemplazando a Btrfs, pero señalan que eso está “a muchos años vista”.
• Se considera que Bcachefs ha tenido menos errores históricos, pero aún carece de funcionalidad crítica y de exposición en el mundo real.

Licencias de ZFS y riesgo legal

• Hay debate sobre si la incompatibilidad GPL/CDDL realmente prohíbe distribuir ZFS con Linux; algunos citan la postura de OpenZFS de que los módulos binarios están bien.
• Contraargumento: la teoría legal importa menos que la capacidad de Oracle para causar problemas costosos; las distribuciones conservadoras pueden evitar razonablemente el riesgo.
• Se cita el módulo ZFS de Ubuntu, mantenido durante años sin acción de Oracle, como evidencia de que el riesgo es bajo, pero no nulo.

Experiencias de fiabilidad y corrupción

• Varios usuarios informan de corrupción repetida de Btrfs, a veces irrecuperable, en hardware de consumo, comparándolo desfavorablemente con ext4.
• Otros reportan más de una década de uso estable, incluyendo RAID1 en varios discos y sistemas de larga duración, a veces sobreviviendo a fallos de hardware con reparación manual.
• Consenso: Btrfs tiene aristas peligrosas; algunas cargas de trabajo y configuraciones incorrectas (RAM defectuosa, RAID5/6, cuotas) son arriesgadas.

Rendimiento, trabajo en segundo plano y cuotas

• Hay informes de que los hilos de “cleaner” / tareas en segundo plano de Btrfs consumen mucho CPU en sistemas de gama baja, haciéndolos sentirse inutilizables, especialmente con los valores predeterminados de openSUSE (instantáneas + cuotas).
• Desactivar las cuotas suele aliviar los problemas; eliminar instantáneas con cuotas se señala como especialmente costoso.

Áreas problemáticas conocidas y errores

• Se reconoce ampliamente que RAID5/6 no es seguro; la documentación oficial y las herramientas lo desaconsejan.
• Se describe un error reproducible al convertir ext3 casi lleno a Btrfs y luego desfragmentar con compresión; puede llevar a un “sin espacio” imposible de corregir.
• Se debate que los sistemas de archivos son infraestructura crítica; algunos consideran inaceptable para software de producción el enfoque de “no uses la función X”.
• El bug de condición de carrera del artículo enlazado se considera muy raro en la práctica, pero suscita debate sobre qué tamaño de muestra (por ejemplo, 100 horas-máquina) demuestra realmente algo.

Casos de uso y alternativas

• Muchos eligen ext4 o XFS por su comportamiento “a prueba de bombas” y para cargas de trabajo de bases de datos; se dice que XFS es el preferido por la mayoría de las bases de datos.
• Algunos ejecutan bases de datos (réplicas de PostgreSQL/MySQL, RocksDB) sobre Btrfs o ZFS, a menudo por compresión e instantáneas, aceptando el sobrecoste de CoW.
• Proveedores de NAS como Synology usan Btrfs principalmente encima de RAID clásico, evitando las funciones RAID nativas de Btrfs.

Instantáneas, copias de seguridad y herramientas

• Las instantáneas de Btrfs junto con herramientas como snapper/btrbk son elogiadas por su reversión fácil y copias de seguridad rápidas, especialmente en distribuciones rolling.
• Algunos quieren instantáneas al estilo Btrfs en WSL2; los atajos actuales implican LVM, dm-snapshot o mecanismos futuros como blksnap.

Conversión en sitio y expectativas

• La conversión en sitio de ext→Btrfs se considera por algunos inherentemente arriesgada; otros sostienen que, si está documentada y soportada, debería ser fiable.
• Idea más amplia: para muchos, los sistemas de archivos deben ser “formatear, montar, olvidar”, y los errores se consideran intolerables comparados con fallos de aplicaciones.