Sistema de arquivos BTRFS, compactação e cópia na gravação

Question

Estou planejando mudar do etx4 para o sistema de arquivos BTRFS no meu pc e servidor de backup. Estou muito interessado no recurso de snapshot do BTRFS (eu entendi que ele usa o recurso copy on write) e o recurso de compactação, mas tenho dúvidas / perguntas:

Como a compressão e a vaca interagem / trabalham juntas? A compressão do sistema de arquivos afeta (penaliza) a eficiência da vaca? Alguém aqui usou os dois recursos, vaca e compressão, com o BTRFS e pode confirmar que eles estão funcionando bem juntos?

Atualização : Eu encontrei esta explicação \ resposta dentro do btrfs wiki :

"Como a compactação interage com IO direto ou COW? A compactação não funciona com o DIO, funciona com o COW e não funciona com arquivos NOCOW. Se um arquivo for aberto no modo DIO, ele retornará ao IO em buffer. " Parece que a compressão e o trabalho da vaca estão juntos.

Alguém usou vaca + compressão em produção em conjunto - ou seja, vários instantâneos de pastas compactadas?

    

Answer 1

A compactação BTRFS foi projetada para se encaixar de maneira eficiente com todo o design do CopyOnWrite. Eu uso os dois juntos e posso confirmar que eles não me causaram nenhum problema.

Como eles funcionam juntos: os dados de arquivo no BTRFS são armazenados em extensões, que são longas seções de blocos sequenciais. Os blocos são todos do mesmo tamanho, geralmente 4K, enquanto as extensões variam em tamanho pelo arquivo real e pelo espaço livre. Por exemplo, se você tem um arquivo com tamanho de 1M, pode ser uma extensão de 256 blocos ou duas extensões de 113 blocos e 143 blocos. Ou dezenas de extensões de todos os tamanhos diferentes, em qualquer combinação. Se você alterar um byte no meio do arquivo, ele copiará a extensão que contém o byte alterado. Ele pode criar uma extensão totalmente nova ou dividir essa extensão em três: dois em cada lado do byte alterado, que apontam para os blocos originais inalterados, e um com os novos dados.

A maneira como a compressão se encaixa, de acordo com o wiki btrfs, é que a compressão é feita em uma base bloco por bloco (tamanho 4K), em grupos de blocos de até 128K de tamanho. Portanto, o arquivo não é armazenado em um longo fluxo compactado; Ele é armazenado como seções de blocos compactados. Quando você altera um byte no meio do arquivo, a maioria do arquivo em blocos compactados é intocado. O bloco compactado e, possivelmente, alguns blocos em torno dele até 128K, são copiados e recompactados, e a lista de extensões é atualizada como qualquer outra gravação COW. Nos sistemas atuais, a compactação de 4K ou 128K é trivial, portanto, não há penalidade de desempenho.

Como o ajuste do mapa de extensão do arquivo é uma parte normal da funcionalidade COW, não há diferença significativa em saber se alguns dos blocos de 4K são compactados ou descompactados. (Na verdade, no BTRFS, um arquivo pode incluir qualquer combinação de blocos não compactados, blocos compactados ZLIB e blocos compactados LZO, dependendo de qual opção de compactação estava ativa no sistema de arquivos quando partes do arquivo foram atualizadas.)

Eu não fiz nenhum estudo ou medições exaustivas; "funciona" como eu esperava.