Razonamiento detrás del alojamiento de imágenes de disco virtual en el sistema de archivos BTRFS


10

He estado leyendo sobre BTRFS y ZFS por un tiempo y si bien aprecio los beneficios de CoW al alojar archivos importantes, actualmente me desconcierta el siguiente dilema:

Dado que tanto ZFS como BTRFS parecen sufrir una degradación del rendimiento al alojar archivos grandes sujetos a escrituras aleatorias (por ejemplo, QCOW2, VDI, etc.), ¿por qué alguien usaría BTRFS como un FS de elección para alojar máquinas virtuales?

Sé que en el caso de BTRFS, puede desactivar selectivamente CoW utilizando chattr, o la opción de montaje nodatacow, reduciendo la degradación impuesta por la fragmentación y CoW ...

Sin embargo, de acuerdo con Sombrero rojo esto también "desactiva la verificación de suma de comprobación de datos y metadatos, lo que resulta en una integridad de datos reducida". (Además de la compresión perdida y, naturalmente, el CoW deseado).

Basándome en eso, pregunto: ¿por qué alguien elegiría BTRFS a través de, digamos, XFS sobre LVM sobre MD RAID?


Tenga en cuenta que el integridad de datos reducida sería lo mismo que usar la mayoría de los otros sistemas de archivos como ext4 o xfs que no almacenan sumas de comprobación y, por lo tanto, no pueden detectar daños.
basic6

1
@ basic6 Estoy al tanto. De ahí la pregunta.
Andre de Miranda

Respuestas:


10

Si el caso de uso principal es el almacenamiento de imágenes de VM o bases de datos, y no está interesado en aceptar los posibles problemas de rendimiento para obtener las ventajas de integridad de datos de btrfs, no puedo pensar en ninguna razón por la que querría elegir btrfs. sobre xfs o ext4.

Deshabilitar la copia en escritura solo para el directorio de imágenes de VM (utilizando chattr + C) es más relevante cuando almacenar imágenes de VM es solo uno de los muchos usos que tiene para su sistema de archivos. Entonces puede ser muy conveniente simplemente deshabilitar la copia en escritura para ese directorio único, y aún así conservar todas las ventajas de btrfs para el resto del sistema de archivos.


Una razón sería tener un disco sin una tabla de particiones. BTRFS permite que grub / etc se incruste directamente en él, XFS / EXT4 / etc no ... He estado buscando un sistema de archivos que lo permita como CoW de BTRFS encima del BTRFS que estoy usando para almacenar la VM Las imágenes no son ideales (estoy usando instantáneas y btrfs-RAID10 en el host), y chattr + C parece ser mi única opción fuera de usar una tabla de particiones. Supongo que voy a utilizar una tabla de particiones.
Alex

4

BTRFS tiene un formato de disco diferente que superará a otros sistemas de archivos en algunos patrones de escritura. En particular, se ha invertido una gran cantidad de esfuerzo en mejorar la forma en que se escriben los metadatos en el disco y admite algunas características avanzadas, como la suma de verificación de datos, la compresión y las instantáneas. Para archivos grandes, mejorar el rendimiento de los metadatos generalmente no es importante.

En comparación con ZFS, BTRFS es una solución más simple y mejor soportada en Linux. El principal inconveniente es que no se escala también (al agregar una gran cantidad de discos) y no tiene el mismo conjunto de funciones.

En comparación con XFS, será una solución de menor rendimiento. Es decir. Tomará más tiempo del procesador escribir una porción de datos en el disco y estará limitado en el rendimiento máximo. Esto puede mitigarse hasta cierto punto haciendo cosas como deshabilitar la verificación de suma de comprobación, pero luego pierde el beneficio principal de BTRFS sobre XFS, que es información de metadatos mejorada. Es decir. Suma de comprobación y registro en diario diferente (que puede ser mejor en algunas situaciones).

En términos de compatibilidad con Copia en escritura (COW), XFS favorece el rendimiento en lugar de ser estrictamente COW. Es decir. XFS tiene muy buenas características de metadatos y registro de diario en términos de escalabilidad y, por lo general, no sobrescribirá los datos de archivo en escritura, con la excepción de que permitirá sobrescribir los bloques de disco existentes si la aplicación solicita específicamente sobrescribir esos datos. Esto puede ser bueno en el caso de una máquina virtual, ya que su asignación de disco inicialmente puede ser contigua y, en ese caso, seguirá siendo contigua durante la vida útil de la máquina virtual.


4

Utilizando BTRFS, incluso con nodatacow y por igual todavía eres capaz de crear instantáneas de datos manualmente con CoW comportamiento, por lo que es rápido y no consume mucha memoria. Además, esas instantáneas son más flexibles que usar LVM, ya que no necesita reservar espacio debajo del sistema de archivos que el sistema de archivos no conoce y no puede usar si no es necesario. Al igual que con ZFS, las instantáneas pueden enviarse y recibirse a través de la red, lo que podría ayudarlo a mejorar su estrategia de respaldo. Así que incluso con nodatacow BTRFS parece ser superior al uso de LVM.


0

Después de haber trabajado con plataformas de computación en la nube, he llegado a adoptar su punto de vista de las máquinas virtuales como un contenedor de datos y funcionalidad donde la realidad virtual es de menor importancia.

Prefiero tener implementados buenos procesos de copia de seguridad, restauración e instalación, y me preocupo menos por la integridad de la VM y más sobre el rendimiento.

Es decir. elija JFS / XFS / EXT4 sobre LVM sobre MD-raid en lugar de BTRFS. Asegúrese de que nunca almacene nada que no tenga una copia de seguridad en la VM durante un período de tiempo más prolongado ... y tenga implementados scripts y procedimientos para obtener una nueva instalación de la VM en un tiempo razonable si algo sucediera.

Pero esto es más un escenario de desarrollo / experimento que cualquier otra cosa.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.