BTRFS dentro de VMs de Proxmox: ¿flexibilidad inteligente o trampa de CoW sobre CoW?

¿Conoces ese momento en que estás a punto de elegir un sistema de archivos y te detienes?

Las funciones ya las conoces bastante bien. Te detienes porque te preguntas de qué se va a arrepentir tu yo del futuro, y esa es justo la tensión de este hilo. La pregunta es sencilla a primera vista:

¿Hay algún problema en usar BTRFS dentro de VMs de Proxmox? Me gustaría tener CoW, snapshots y subvolúmenes. Pero no quiero meterme yo solo en un rincón que no veo venir.

Esa última frase te dice casi todo lo que necesitas saber. Ya nadie pregunta por BTRFS a la ligera. Preguntas porque quieres su potencia y también sabes que internet está lleno de batallitas. Esto es lo que salió de verdad de la discusión.

Primero: ¿qué ejecuta el host?

La primera respuesta no discutió las funciones de BTRFS. Preguntó una sola cosa:

¿Qué sistema de archivos usas en el host? Si es ZFS, lo vas a pasar mal por la amplificación de escritura.

Zas. Ahora la pregunta ya no va de BTRFS aislado. Va de apilar copy-on-write encima de copy-on-write, y ahí es donde la cosa se pone picante.

Si tu host Proxmox ejecuta ZFS y dentro de la VM ejecutas BTRFS, en la práctica estás anidando comportamiento CoW. Cada escritura en el invitado se convierte en una operación CoW, y luego el host trata esa escritura como otra operación CoW. Eso puede multiplicar muy rápido la carga de E/S. Alguien lo dijo sin rodeos:

Normalmente usar un CoW dentro de otro CoW es mala idea en cuanto a rendimiento.

Es física pura y simple.

Un momento, el host es ext4

El autor original aclaró que el sistema de archivos del host es ext4, y eso cambia el tono al instante. Ya no hay nada apilado. La configuración es:

• ext4 en el host
• BTRFS dentro de la VM

Es mucho más limpio, y la respuesta fue:

Entonces no me preocupa nada.

Esa fue toda la respuesta, sin drama ni avisos apocalípticos, lo que demuestra cuánto importa el contexto.

Los argumentos a favor de BTRFS en VMs

En el hilo hubo voces muy a favor de BTRFS. Una persona lo expuso con claridad:

• Está bien para producción.
• OpenSUSE lo trae por defecto.
• Simplemente evita el RAID5/6 de BTRFS.

Esa última parte es importante. La implementación de RAID5/6 sigue en terreno "experimental", pero RAID1 (espejo) es sólido, y un solo disco también va bien.

Otro usuario lleva más de un año usando BTRFS en VMs con Debian:

Los snapshots antes de actualizar me han salvado un par de veces.

Para mucha gente, esa es la función estrella. Dentro de una VM, los snapshots de BTRFS son ridículamente cómodos. Haces uno antes de una actualización, antes de tocar configuraciones o antes de probar algo arriesgado, y puedes volver atrás en segundos. Sin restauración a nivel de hipervisor y sin revertir la imagen completa, solo viajes en el tiempo a nivel de sistema de archivos.

Luego está el redimensionado. Un comentarista señaló algo que está de verdad infravalorado:

En una VM me encanta que BTRFS pueda redimensionarse en las dos direcciones.

Ampliar sistemas de archivos es habitual, mientras que reducirlos suele ser donde las cosas se ponen feas. BTRFS puede hacer las dos cosas, y en un laboratorio o en casa, donde las necesidades de almacenamiento cambian constantemente, esa flexibilidad es enorme.

Los argumentos en contra de BTRFS

Luego está el bagaje emocional. Varios usuarios aportaron variaciones de la misma historia: "Tuve una mala experiencia", "Perdí el array entero", "No arrancaba después de una actualización", "Me quitó las ganas para siempre".

No eran pequeñas molestias. Eran pesadillas de reconstrucción de varios terabytes. Una persona perdió un sistema BTRFS virtualizado tras una actualización y ni siquiera intentó recuperarlo; simplemente pasó página. Otra perdió un array de varios terabytes y pasó semanas reconstruyendo un servidor Plex. Una experiencia así se queda grabada.

Eso sí, hay un patrón. La mayoría de estas historias de terror no trataban de un BTRFS sencillo de un solo disco dentro de una VM. Trataban de:

• Configuraciones RAID
• Implementaciones antiguas
• Montajes de casos límite

Aun así, al miedo le dan igual los matices.

El bando de "usa ext4 y ya"

En estos hilos siempre hay una voz que dice "ext4, salvo que necesites otra cosa".

Un comentarista contó que en la gran empresa donde trabaja usan ext4 por defecto para los sistemas de archivos sin redundancia, porque está probado, es aburrido y funciona. Lo aburrido está infravalorado.

Otra persona eligió LVM/ext4 sobre todo por la coherencia de las copias de seguridad. BTRFS no le fallaba; sencillamente ganó la simplicidad. Hay algo de sabiduría en eso. Si no necesitas sí o sí las funciones CoW dentro de la VM y ya haces snapshots a nivel de hipervisor, puede que BTRFS sea redundante.

El ángulo oculto: las funciones del host

Un comentario pasó por encima de toda la lista de funciones:

No sacarías ningún beneficio real de la VM. Los snapshots y el aprovisionamiento ligero son más cosa del host.

Es un argumento justo. Si tu host Proxmox ejecuta ZFS, ya tienes:

• Snapshots
• Sumas de verificación
• Aprovisionamiento ligero
• Compresión

¿De verdad necesitas BTRFS también dentro del invitado? Quizá no. Pero si tu host es ext4, la cuenta cambia.

La sorpresa de la deduplicación

Uno de los comentarios más interesantes vino de alguien que usa BTRFS como destino de copias de seguridad. Guarda más de 600 backups en un disco de 10TB y solo está al 70% de capacidad, gracias a la deduplicación a nivel de bloque.

En entornos con muchas copias de seguridad, sobre todo donde la mayoría de los datos cambia poco entre versiones, BTRFS puede compactar mucho. Es densidad en el mundo real, y cuesta ignorar una eficiencia así.

Entonces… ¿es una trampa?

Si miras el hilo con perspectiva, no grita "huye". Dice "conoce tu pila". Esta es la versión destilada.

Escenarios más o menos seguros

• El host es ext4 o no usa CoW.
• BTRFS de un solo disco dentro de la VM.
• Solo RAID1/10.
• Entiendes los snapshots y los subvolúmenes.
• Mantienes copias de seguridad fuera de la VM.

Escenarios más arriesgados

• ZFS en el host + BTRFS en el invitado.
• RAID5/6 en BTRFS.
• Ningún plan de backup.
• Cargas de trabajo sensibles al rendimiento sobre CoW anidado.

Cuando algo sale mal, las expectativas desajustadas suelen merecer más culpa que el sistema de archivos.

La parte psicológica que la gente se salta

Elegir BTRFS también es cuestión de personalidad. ¿Estás cómodo depurando casos límite raros, dispuesto a leer logs del kernel, tranquilo aprendiendo herramientas de recuperación y con un homelab donde experimentar es parte de la diversión? ¿O quieres cero drama, cero sorpresas y la máxima previsibilidad?

Hay gente que nunca volverá a fiarse de BTRFS por algo que le hizo hace años, esté como esté ahora. Es legítimo. El trauma del almacenamiento es real.

La postura del autor original

Hay un detalle que importa mucho:

Llevo más de una década usando BTRFS en mi servidor de casa. Un cuelgue del kernel, quizá causado por BTRFS. Aparte de eso, ningún problema.

Es alguien que ya conoce el sistema de archivos, no alguien que se lanza a ciegas a un terreno nuevo, y eso lo cambia todo. El peligro viene de no conocer el sistema de archivos.

El veredicto

Si tu host Proxmox ejecuta ext4 y quieres BTRFS dentro de tus VMs Linux por los snapshots, los subvolúmenes, el redimensionado flexible o para experimentar en el laboratorio, no te estás metiendo en un desastre. Solo:

• Evita RAID5/6.
• Ten copias de seguridad de verdad.
• No apiles CoW sobre CoW salvo que entiendas el coste.

Si ya ejecutas ZFS en el host, piénsalo mejor, porque puede que estés duplicando funciones y multiplicando la sobrecarga.

Aquí no hay un sí o un no sencillo; depende de conocer tu pila. Y si llevas diez años usando BTRFS sin problemas, estás eligiendo una herramienta que ya sabes manejar.