Usei para teste uma instalação do Arch
Linux + KDE (completo) + aplicativos comuns em desktop, e exclui destas estatísticas a partição
/home (esta em outra partição) e
/boot (esta em outra partição), em um SSD com interface SATA e com partição de 40 GB.
Fiz os testes em duas rodadas, sendo uma com restauração de snapshot (arquivos compactados com origem comum) e posterior compactação, e outro com compactação sobre o sistema já compactado, previamente com zlib. Nos algorítimos zlib e zstd, foram usados os níveis de compactação padrão de cada um (3).
Foi usado a metodologia de desfragmentação (descrito no capitulo anterior) para se conseguir compactar os arquivos. Os resultados para a compactação sobre os arquivos previamente não compactados:
- 27 GB livres sem compactação
- 31,6 GB livres com compactação zlib
- 30,3 GB livres com compactação lzo
- 31,8 GB livres com compactação zstd
Na segunda rodada, curiosamente, o resultado foi diferente da primeira (recompactação sobre o zlib):
- 29,9 GB livres com compactação lzo
- 31,5 GB livres com compactação zstd
Como foi possível ver, o zstd é o que apresentou o melhor nível de compactação (mais espaço livre), e apesar de não cronometrar o tempo que cada um demorou para realizar a tarefa, é facilmente perceptível que o zlib foi (muito) mais lento, seguido pelo zstd e lzo, porém, o nível de compressão do zstd foi superior ao lzo.
Continuando os testes, mudando a compressão de um tipo para o outro, em momentos diferentes a diferença era de 0,01 GB para mais ou para menos, e eu não consegui definir o por quê aconteceu isso.
Uma imagem demonstrando o particionamento do disco. Os valores estão diferentes por causa do print ter sido tirado em um dia diferente dos testes, servindo apenas para demonstrar o esquema de particionamento. A SWAP está em outro disco:
Exemplo de FSTAB
Em meu sistema, estou usando apenas três subvolumes, um para o sistema, outro para o cache de pacotes (economia de espaço nos snapshots) e o último para os snapshots.
As opções importantes são o "subvol=@ subvol=@pkg subvol=@snapshots" que indica o subvolume e ponto de montagem, e a opção "compress=zstd:15", que indica a compactação. Outra opção interessante, mas que não uso, é a opção "autodefrag".
# Static information about the filesystems.
# See fstab(5) for details.
# <file system> <dir> <type> <options> <dump> <pass>
# /dev/sda1 LABEL=boot
UUID=38a3bd5b-a4cf-4e94-9a3d-d5e72f1f281b /boot ext4 rw,noatime 0 2
# /dev/sda2 LABEL=root
UUID=6b84c79a-03e1-4c73-801e-612443ac54ad / btrfs rw,noatime,ssd,space_cache,compress=zstd:15,subvol=@ 0 0
# /dev/sda2 LABEL=root
UUID=6b84c79a-03e1-4c73-801e-612443ac54ad /var/cache/pacman/pkg btrfs rw,noatime,ssd,space_cache,compress=zstd:15,subvol=@pkg 0 0
# /dev/sda2 LABEL=root
UUID=6b84c79a-03e1-4c73-801e-612443ac54ad /.snapshots btrfs rw,noatime,ssd,space_cache,compress=zstd:15,subvol=@snapshots 0 0
# /dev/sda3
UUID=0d5acd37-ee72-40c0-8e50-dc75eab03271 /home xfs rw,noatime,attr2,inode64,noquota 0 2
# /dev/sdb2 LABEL=efi
UUID=0297-A118 /boot/efi vfat rw,noatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 2
# /dev/sdb5
UUID=a39676a9-992a-47ee-80f8-6bce8fc1b1a9 none swap defaults 0 0
Considerações Finais
O sistema de arquivo BTRFS já se mostra bastante estável para uso, mas ainda possui recursos não totalmente estáveis, como é possível ver:
Alguns exemplos de testes de desempenho do BTRFS:
Para quem dispões de pouco espaço, pode salvar alguns GBs muito importantes. E para quem tem banco de dados, pode economizar muitos GBs.
Apesar de ótimo desempenho, o zlib e lzo apresentam maior compatibilidade com versões mais antigas do kernel e do btrfs-progs e principalmente com o Grub, dependendo da distro, estas podem ser escolhas melhores caso queira usar compactação.
Níveis de compactação mais altos podem tornar o sistema lento, mas também apresentam resultados significativos quanto a uso de espaço. Tanto o zlib uanto o zstd apresentam grande taxa de compactação.
O openZFS possui recursos interessantes e muito promissores, mas sua utilização me parece mais trabalhosa do que a do BTRFS, que já é nativa no mundo Linux.
O openSUSE hoje, me parece uma das melhores opções para se usar o BTRFS, principalmente pela facilidade de instalação, e em modo gráfico. O esquema proposto pela distro é bastante funcional.
Muitos snapshots, com o tempo, irão consumir muito espaço com o tempo, então é preciso ter isso em mente quando decidir o tamanho da partição e sempre observar o uso de espaço.
Ferramentas como o Snapper e o TimeShift podem ser muito interessantes, mas eu as vejo muito mais para o gerenciamento apenas de arquivos, do que para restauração em caso de problemas sério no sistema.
O objetivo deste artigo é ser algo simples e direcionado à pessoas que não conhecem, ou muito pouco sabem sobre este sistema de arquivos. Conteúdo sobre este tema em língua inglesa é bastante extenso e detalhado, mas em português ainda existe pouco conteúdo, menos ainda explicativo e com exemplos.
Meu conhecimento sobre este tema ainda é bastante raso, e o que foi exposto reflete apenas o que aprendi no pouco tempo que me dediquei a usar o BTRFS, pretendo em um futuro atualizar este artigo com correções e novas informações, mas por hora é o que posso contribuir.
Referências