Toca do Tux: Btrfs: Uma breve comparação com o ZFS

Imagem reaproveitada do meu próprio vídeo "ZFS VS Btrfs №1: Quem vence essa batalha?" (informação adicionada em 31/07/2021)

Ontem eu publiquei o vídeo de aniversário do Btrfs (que espero terem gostado. Já deixo-os ciente de que a festa ainda não acabou hehehe).

Quando o ZFS foi iniciado, a perspectiva para o file systems no Solaris também era escura. Logging UFS já estava aproximando do fim fim da linha em termos de tamanho de file system size e desempenho. UFS estava de longe atrás que clientes do Solaris pagaram somas substanciais em dinheiro para a Veritas rodar o VxFS.

O Solaris precisava de um novo file system, e precisava em breve. Jeff Bonwick decidiu resolver o problema e iniciar o projeto ZFS dentro Sun. Sua metáfora de se organizar era aquela do subsistema da memória virtual:

"Por que o disco não pode ser fácil de administrar e utilizar quando a memória? "

A estrutura central de dado ondisk era a laje, um naco de dispositivo de disco divididos em blocos do mesmo tamanho, como aquele no alocador de memória do kernel SLAB, que ele também criou. Ao invés de extents, ZFS utilizaria um block pointer por bloco, mas cada objeto utilizaria um tamanho de bloco diferente. E.g., 512 bytes, ou 128KB dependendo do tamanho do objeto. Endereços de blocos seriam traduzidos através de um tipo de meconismo de memória virtual, assim os blocos poderiam ser realocados sem o conhecimento das camadas mais alta. Todos os dados e metadados do file system seria armazenados em objetos. E todas as mudanças no file system seriam descritas em termos de mudanças para objetos, que seriam escritas em um estilo copyonwrite.

Em resumo, btrfs organiza tudo no disco dentro de uma btree de extents contendo itess e dados. ZFS organiza tudo no disco dentro de uma árvore de apontadores de bloco, com tamanhos diferentes de bloco dependendo no tamanho do objeto. Btrfs realiza checksums e re-confere os extents; o ZFS realiza checksums e re-confere tamanhos variáveis de blocos. Ambos os file systems escrevem as alterações no disco utilizando CopyonWrite extents ou blocos em uso não são sobre escritos no lugar, eles são sempre copiados em algum outro lugar primeiro.

Então, enquanto a lista de recurso dos dois file systems parecem bastante similares, as implementações são completamente diferentes. É um pouco de evolução convergente entre marsupiais e mamíferos placentários. Um rato marsupial e um rato placental parecem bem idênticos por fora, mas suas implementações internas são um bocado diferentes!

Na minha opinião, a arquitetura básica do btrfs é mais adequada do que a do ZFS. Um dos maiores problemas com a abordagem do ZFS "slabs" de blocos de um tamanho particular é fragmentado. Cada objeto pode conter blocos de somente um tamanho, e cada slab pode somente conter blocos de um tamanho. Você pode facilmente acabar com, por exemplo, um arquivo de blocos do tamanho de 64K que precisam crescer um blocos ou mais, mas nenhum bloco to tamanho de 64K estão disponíveis, mesmo que o file system esteja cheio de bem perto de slabs vazios com blocos do tamanho de 512 byte, 4K, 128K e etc. Para solucionar esse problema, nós (os desenvolvedores do ZFS) inventamos meios de criar grandes blocos fora de pequenos blocos ("gang blocks") e outros trabalhos desagradáveis. Em nossa defesa, no tempo que btrees e extents aparentavam fundamentalmente incompatíveis com copyonwrite, e a metáfora da memória virtual metaphor nos serviram bem em muitos outros respeitos.

Em contraste, os itens em uma abordagem btree são extremamente eficientes e flexíveis em espaço. Desfragmentação é um processo em curso reempacotando os itens eficientemente é parte do caminho do código normal preparando extents para serem escritos no disco. Fazer checksums, reference counting e outros metadados variados em uma base por extent reduz a sobrecarga e torna novos recursos (tal como reverso de mapiamento rápido de um extent tudo que refere-se) possível.

Agora, para algumas predições pessoais (baseada puramente em informações publicas, eu não tenho nenhum conhecimento de informante). Btrfs será o file system padrão no Linux dentro de dois anos. Btrfs como um projeto não será (e não pode, a esse ponto) ser cancelado pela Oracle. Se todas as propriedades intelectuais estão funcionando (um grande se), ZFS será portado para Linux, mas ele terá menos de um pouco percentual da base instalada do btrfs.

Verifiquem daqui a dois anos e vejam se eu eu estou certo dessa predições!*

*Este artigo foi escrito em 22 de Julho de 2009