Raciocínio por trás da hospedagem de imagens de disco virtual no sistema de arquivos BTRFS


14

Eu tenho lido sobre o BTRFS e o ZFS por um tempo e, embora aprecie os benefícios do CoW ao hospedar arquivos importantes, estou atualmente intrigado com o seguinte dilema:

Dado que o ZFS e o BTRFS parecem sofrer uma degradação do desempenho ao hospedar arquivos grandes sujeitos a gravações aleatórias (por exemplo, QCOW2, VDIs etc.), por que alguém usaria o BTRFS como um FS de escolha para hospedar VMs?

Eu sei que no caso do BTRFS você pode desativar seletivamente o CoW usando o chattr, ou a opção de montagem nodatacow, reduzindo a degradação imposta pela fragmentação e pelo CoW ...

No entanto, de acordo com Redhat, isso também "desativa a verificação de soma de verificação de dados e metadados, resultando em menor integridade dos dados". (além da compressão perdida e, naturalmente, o desejado CoW).

Com base nisso, pergunto: Por que alguém escolheria o BTRFS sobre, digamos, XFS sobre LVM sobre MD RAID?


Observe que a integridade reduzida dos dados seria o mesmo que usar a maioria dos outros sistemas de arquivos como ext4 ou xfs, que não armazenam somas de verificação e, portanto, são incapazes de detectar corrupção.
usar o seguinte comando

1
@ basic6 Estou ciente. Daí a questão.
Andre de Miranda

Respostas:


13

Se o caso de uso principal estiver armazenando imagens ou bancos de dados de VMs e você não estiver interessado em aceitar os possíveis problemas de desempenho para obter as vantagens de integridade de dados do btrfs, não consigo pensar em nenhum motivo para escolher o btrfs sobre xfs ou ext4.

Desabilitar a cópia na gravação apenas para o diretório de imagens da VM (usando o chattr + C) é principalmente relevante quando o armazenamento de imagens da VM é apenas um dos muitos usos que você tem para o seu sistema de arquivos. Então, pode ser muito conveniente desabilitar a cópia na gravação para esse diretório único, mantendo ainda todas as vantagens do btrfs para o restante do sistema de arquivos.


Um motivo seria ter um disco sem uma tabela de partição. O BTRFS permite que o grub / etc seja incorporado diretamente nele, o XFS / EXT4 / etc não. Eu estive procurando por um sistema de arquivos que o permita como o COW do BTRFS sobre o BTRFS que estou usando para armazenar a VM images não é o ideal (estou usando snapshots e btrfs-RAID10 no host), e o chattr + C parece ser minha única opção fora do uso de uma tabela de partição. Acho que vou usar uma tabela de partição.
11118 Alex

5

O BTRFS possui um formato de disco diferente que superará outros sistemas de arquivos em alguns padrões de gravação. Em particular, uma grande quantidade de esforço foi gasta na melhoria de como os metadados são gravados no disco e suporta alguns recursos avançados, como soma de verificação de dados, compactação e snapshots. Para arquivos grandes, melhorar o desempenho de metadados geralmente não é importante.

Comparado ao ZFS, o BTRFS é uma solução mais simples e com melhor suporte no Linux. A principal desvantagem é que ela não é dimensionada também (ao adicionar um grande número de discos) e não possui o mesmo conjunto de recursos.

Comparado ao XFS, será uma solução de desempenho mais baixo. Ou seja, levará mais tempo do processador para gravar um pedaço de dados no disco e será limitado na taxa de transferência máxima. Isso pode ser atenuado, até certo ponto, com a desativação da verificação da soma de verificação, mas você perde o benefício principal do BTRFS sobre o XFS, que são informações aprimoradas de metadados. Ou seja, soma de verificação e registro no diário diferente (o que pode ser melhor em algumas situações).

Em termos de suporte à cópia na gravação (COW), o XFS favorece o desempenho em vez de ser estritamente COW. Ou seja, o XFS possui recursos de metadados e registro no diário muito bons em termos de escalabilidade e geralmente não substitui os dados do arquivo durante a gravação, com a exceção de que permitirá que os blocos de disco existentes sejam substituídos se o aplicativo solicitar especificamente a substituição desses dados. . Isso pode ser bom no caso de uma VM, pois sua alocação de disco inicialmente pode ser contígua e, nesse caso, permaneceria contígua durante toda a vida útil da VM.


5

Usando o BTRFS, mesmo com nodatacowe similares, você ainda pode criar instantâneos de dados manualmente com CoWcomportamento, por isso é rápido e não consome muita memória. Além disso, esses instantâneos são mais flexíveis do que usar o LVM, porque você não precisa reservar espaço abaixo do sistema de arquivos do qual o sistema de arquivos não está ciente e não pode ser usado se não for necessário. Como no ZFS, os snapshots podem ser enviados e recebidos pela rede, o que pode ajudá-lo a melhorar sua estratégia de backup. Portanto, mesmo com o nodatacowBTRFS parece ser superior ao uso do LVM.


3

Depois de trabalhar com plataformas de computação em nuvem, adotei sua visão de máquinas virtuais como um contêiner para dados e funcionalidade em que a VM real é de menor importância.

Prefiro ter bons processos de restauração, backup e instalação e implantação, além de me preocupar menos com a integridade da VM e mais com o desempenho.

Ou seja, vá para JFS / XFS / EXT4 sobre LVM sobre MD-raid em vez de BTRFS. Certifique-se de que eu nunca armazene nada que não esteja em backup na VM por mais tempo ... e tenha scripts e procedimentos para obter uma nova instalação da VM em um tempo razoável, caso algo aconteça.

Mas esse é mais um cenário de desenvolvimento / experiência do que qualquer outra coisa.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.