Raison derrière l'hébergement d'images de disque virtuel sur le système de fichiers BTRFS

Je lis sur BTRFS et ZFS depuis un certain temps et bien que j'apprécie les avantages de CoW lors de l'hébergement de fichiers importants, je suis actuellement perplexe devant le dilemme suivant:

Étant donné que ZFS et BTRFS semblent souffrir d'une dégradation des performances lors de l'hébergement de gros fichiers soumis à des écritures aléatoires (par exemple QCOW2, VDI, etc.), pourquoi quelqu'un utiliserait-il BTRFS comme FS de choix pour héberger des machines virtuelles?

Je sais que dans le cas o BTRFS, vous pouvez désactiver sélectivement CoW en utilisant chattr, ou l'option de montage nodatacow, réduisant la dégradation imposée par la fragmentation et CoW ...

Cependant, selon Redhat, cela "désactive également la vérification de la somme de contrôle des données et des métadonnées, ce qui réduit l'intégrité des données". (en plus de la compression perdue et naturellement du CoW tant souhaité).

Sur cette base, je demande: pourquoi quelqu'un choisirait BTRFS plutôt que disons, XFS plutôt que LVM plutôt que MD RAID?

Si le cas d'utilisation principal est le stockage d'images ou de bases de données de machines virtuelles et que vous n'êtes pas intéressé à accepter les problèmes de performances potentiels afin d'obtenir les avantages d'intégrité des données de btrfs, je ne peux pas penser à une raison pour laquelle vous voudriez choisir btrfs sur xfs ou ext4.

La désactivation de la copie sur écriture pour le répertoire d'images VM uniquement (à l'aide de chattr + C) est principalement pertinente lorsque le stockage d'images VM n'est qu'une des nombreuses utilisations que vous avez pour votre système de fichiers. Ensuite, il peut être très pratique de simplement désactiver la copie sur écriture pour ce répertoire unique, tout en conservant tous les avantages de btrfs pour le reste du système de fichiers.

BTRFS a un format de disque différent qui surpassera les autres systèmes de fichiers sur certains modèles d'écriture. En particulier, de gros efforts ont été consacrés à l'amélioration de la façon dont les métadonnées sont écrites sur le disque et il prend en charge certaines fonctionnalités avancées telles que la somme de contrôle des données, la compression et les instantanés. Pour les fichiers volumineux, l'amélioration des performances des métadonnées n'est généralement pas importante.

Comparé à ZFS, BTRFS est une solution plus simple et mieux prise en charge sous Linux. L'inconvénient majeur est qu'il n'évolue pas aussi bien (lors de l'ajout d'un grand nombre de disques) et n'a pas le même ensemble de fonctionnalités.

Comparé à XFS, ce sera une solution moins performante. C'est-à-dire qu'il faudra plus de temps au processeur pour écrire un bloc de données sur le disque et son débit maximal sera limité. Cela peut être atténué dans une certaine mesure en faisant des choses comme la désactivation de la vérification de la somme de contrôle, mais vous perdez ensuite le principal avantage de BTRFS par rapport à XFS qui est l'amélioration des informations de métadonnées. C'est-à-dire la somme de contrôle et la journalisation différente (ce qui peut être mieux dans certaines situations).

En termes de prise en charge de la copie en écriture (COW), XFS privilégie les performances plutôt que d'être strictement COW. C'est-à-dire que XFS a de très bonnes métadonnées et des fonctions de journalisation en termes d'évolutivité et ne remplacera généralement pas les données de fichier lors de l'écriture, à l'exception du fait qu'il permettra aux blocs de disque existants d'être écrasés si l'application demande spécifiquement de écraser ces données . Cela peut être bon dans le cas d'une machine virtuelle, car votre allocation de disque peut initialement être contiguë et dans ce cas, elle restera contiguë pour la durée de vie de la machine virtuelle.

En utilisant BTRFS, même avec nodatacowet de la même manière, vous pouvez toujours créer des instantanés de données manuellement avec un CoWcomportement, donc c'est rapide et ne consomme pas beaucoup de mémoire. De plus, ces instantanés sont plus flexibles que l'utilisation de LVM, car vous n'avez pas besoin de réserver de l'espace sous le système de fichiers dont le système de fichiers n'a pas connaissance et ne peut pas être utilisé s'il n'est pas nécessaire du tout. Comme avec ZFS, les instantanés peuvent être envoyés et reçus sur le réseau, ce qui pourrait vous aider à améliorer votre stratégie de sauvegarde. Ainsi, même avec nodatacowBTRFS semble être supérieur à l'utilisation de LVM.

Après avoir travaillé avec des plates-formes de cloud computing, j'en suis venu à adopter leur vision des machines virtuelles en tant que conteneur de données et de fonctionnalités où le vm réel a moins d'importance.

Je préfère avoir de bons processus de sauvegarde-restauration et d'installation-déploiement en place et me soucier moins de l'intégrité de la machine virtuelle et plus des performances.

C'est à dire opter pour JFS / XFS / EXT4 sur LVM sur MD-raid plutôt que sur BTRFS. Assurez-vous de ne jamais stocker quoi que ce soit qui ne soit pas sauvegardé sur la machine virtuelle pendant une période plus longue ... et d'avoir des scripts et des procédures en place pour obtenir une nouvelle installation de la machine virtuelle dans un délai raisonnable en cas de problème.

Mais c'est plus un scénario de développement / expérience qu'autre chose.