Então pessoal,
Para quem usa btrfs, qual a melhor compressão em tamanho e performance?
NO link abaixo mostra o Zstd, que é o que estou usando agora
1 curtida
Eu não vejo sentido eu usar uma compressão que tenha equilíbrio entre compressão e performance eu uso a que tem mais compressão mais a escolha é pessoal.
1 curtida
O padrão é o zlib. Acho que é o que tem melhor compressão.
Estou testando aqui. A diferença é de 4GB, mas parece que tem uma resposta melhor.
Mais la tem “Btrfs Defaults” e “zlib Compression”
O “Btrfs Defaults” só pode ser o Btrfs sem usar compressão.
Sim existe casos em que usar compressão em algumas tarefas aumenta a performance.
2 curtidas
Estou ainda aprendendo…
Estou tentando ler informações do btrs sempre que tenho um tempo.
Por padrão acho que ele utiliza o zlib, o Btrfs Defaults é o zlib. Mas como falei estou aprendendo e posso estar errado.
Vamos esperar o @Deleterium…
Ele tem bastante informação sobre btrfs
Po estou dizendo do “Btrfs Defaults” do berchimark o Btrfs Defaults lá é o sem compressão.
Se o zlib é o default eu não sei.
Leia esso a que:
https://wiki.archlinux.org/index.php/Btrfs_(Português)
1 curtida
Ok…
Vou ler…
Estou falando isso, pois no opensuse ao instalar estava com 12GB e depois de comprimir ficou com 16GB
Não cheguei a fazer o teste com zlib
Obrigado pela lembrança!
O BTRFS é extremamente versátil em compressão. Eu não realizei testes, aceitei o que esta escrito na prórpia wiki do btrfs que fala que zlib compacta mais com mais esforço computacional, lzo compacta menos com menos esforço computacional, e zstd é uma opção equilibrada.
Mas o mais interessante é que dá para definir a compactação por pasta ou ainda por arquivo. Então quanto mais vc conhece o seu sistema, mais sabe quais pastas e arquivos vão se beneficiar de cada tipo de compressão ou ainda vão funcionar melhor sem compressão. Se vc tem um banco de dados (caso do benchmark) faz sentido fazer testes para ver o comportamento dele e qual é melhor. Muitos até dizem que a princípio é melhor não usar compressão por conta dos diversos acessos aleatórios, que podem pegar no meio de blocos de compressão, ou inserção de valores , enfim… todas essas variáveis.
Acredito que para uso comum do pc é vantajoso usar a compactação caso espaço disponível seja reduzido. A vantagem de ter mais espaço já é bem grande mesmo considerando a menor compressão, lzo. A minha opinião é: Se precisar, use qualquer uma que já fará grande diferença!
Já para usos específicos, vale a pena fazer teste. Imagine alguém que trabalha com edição de vídeos. Essa pessoa poderia criar 3 diretórios e deixar um sem compactação, um com baixa compactação (lzo) e o terceiro com alta compactação (zlib). Então quando material bruto chega, ela coloca na pasta LZO. Ao selecionar os clipes para trabalhar, usa o espaço temporário na pasta sem compactação durante o processo de edição. Quando termina um vídeo, pode então colocar o video finalizado na terceira pasta com alta compactação.
Por isso eu sou mais adepto de usar compactação por pastas, em vez do disco inteiro. No meu computador só faz sentido compactar o /usr, pois o /var é bem grande mas apenas no cache de pacotes que já são comptactados. Os demais diretórios ocupam bem pouco espaço. O /home está em outra partição e escolhi deixar sem compactação pois há bastante espaço disponível.
1 curtida
Você poderia me passar como/onde encontro alguma referencia de como faço isso, compactar pastas ao invés de partições no btrfs, eu agradeceria.
Acredito que no geral a compressão só é recomendada quando se procura mais espaço. Estou certo que, relativo a performance, a maquina aloca mais recursos pra trabalhar já que precisa descomprimir os dados em disco pra processá-los.
Procurando pela web encontrei esta planilha, nesta página. Posso não ter feito uma boa análise de resultados, mas pelo que vi o melhor custo benefício é a compressão zstd no nível 2.
Eu usei a wiki do próprio btrfs, Compression - btrfs Wiki e do gentoo Btrfs - Gentoo Wiki Uma pena estarem apenas em inglês.
Começando do começo:
- Arquivos e diretórios tem atributos que são reveladas com o comando
ls -lna linha de comando ou, no gerenciador de arquivos, geralmente através do clique direito em “propriedades”. Os atributos básicos são usuário, grupo e permissões de ler, escrever ou executar. - No btrfs além dos atributos básicos também há atributos específicos que podem ser visualizados com o comando
lsattrUm desses atributos é o de compressão. - Quando se adiciona atributo de compressão de um arquivo com o comando
chattr +c <file>oubtrfs property set <file> compression <zlib|lzo|zstd>, ele não é recomprimido na hora. Apenas novas gravações que serão guardadas com compressão. A compressão funciona a nível de bloco do sistema de arquivos, então é possível que ao adicionar mais conteúdo ao arquivo, a parte antiga fique sem compressão e a parte nova seja guardada com compressão. - Há solução para recomprimir todo o conteúdo do arquivo ou o diretório recursivamente. Para isso force a desfragmentação do diretório:
btrfs filesystem defragment -r -v -czlib <diretorio>Para outros algoritmos de compressão troque-czlibpor-clzoou-czstd. Para recomprimir um arquivo, apenas retire a opção de recursividade-re use o nome do arquivo. - Se quiser reverter o processo, remova o atributo de compressão com
chattr -c <arquivo>oubtrfs property set <file> compression ""O conteúdo do arquivo não será descomprimido na hora, apenas as novas atualizações que não serão comprimidas. - Não existe comando para forçar a descompressão dos arquivos. Segundo a wiki do btrfs essa funcionalidade ainda não foi implementada (btrfs versao 4.14).
- O comando chattr pode ser usados em diretórios recursivamente Use
chattr -R +c <diretorio> - Usando o comando chattr não é possível escolher o algoritmo de compressão. Será usado o padrão do btrfs que pode variar conforme a versão e distribuição linux.
Acredito que com esse manualzinho já dá pra brincar de compressão!
Ainda em tempo:
- Ao marcar um diretório com compressão, os novos arquivos e diretórios dentro dele vão herdar essa característica.
- Em uma situação hipotética, é possível selecionar um tipo de compressão para um arquivo, adicionar conteúdo, depois trocar o tipo de compressão, adicionar mais conteúdo e repetir mais uma vez com o terceiro tipo de compressão! No final o arquivo ficará com parte sem compressão, parte com zlib, parte com lzo e parte com zstd! Para o usuário isso fica transparente, pois o tipo de compressão fica marcado na estrutura de blocos do sistema de arquivos (metadados).
1 curtida
O snnaper salva automaticamente ou tem que criar um agendamento para o seriço?
No opensuse é criando uma entrada no grub, em outras distros tem que fazer manualmente?
No opensuse estas entradas são somente leitura, como faz para restaurar?
Em outras distros tem, como faz o processo de restauração?
A compressão não interfere com os snapshots. O snapper vai continuar fazendo o trabalho dele armazenando as diferenças. Porém se você recomprimir todo o sistema de arquivos, a diferença será de todos os arquivos, ou seja, se você tem snapshots e recomprimir tudo, vai quase que dobrar o espaço ocupado.
Para evitar isso, teria que se apagar todos os snapshots e daí sim executar a compressão com btrfs defrag
No uso normal, ao se marcar todos os arquivos para compressão, apenas a diferença será comprimida e não vai interferir com os snapshots anteriores ao processo.
Se decidir não usar mais compressão, parte dessas modificações que foram feitas na epoca em que se usava compressão continuarão comprimidas, inclusive nos snapshots.
Aconteceu isso e fiquei sem espaço…
Resolvi…
O problema que ao apagar o snapshots. Não consegui mais criar o snapshots tmp.
Estou tentando ler o que encontro , mas até agora sem resposta.
Cheguei a remover o snapper e o volume .snapshots…
Desinstalei tudo e até agora nada…
Cria todos os outros, menos o tmp
Obrigado pela referência.
Que estranho o comportamento.
Eu sei que ao se apagar o snapshot ainda não é liberado espaço em disco. Isso vai acontecer através de tarefa agendada ou ainda executando manualmente o btrfs balance
Sobre o tmp, é comum que não se faça snapshot desse diretório, ou ainda alguns casos que se monte como tmpfs (minha opção) para sequer escrever informação no disco. Teoricamente o processo de compressão em nada deve afetar a criação de subvolumes…