Tudo sobre o BTRFS!

Conheça tudo sobre o btrfs, este sistema de arquivos moderno e seguro, que trouxe recursos especiais para quem utiliza SSD ou NVMe!

---

| Se você apoia nosso site, desative o AdBlock quando visitá-lo, inclusive em Mobile!
Os anúncios são poucos e não invasivos. Se quiser contribuir com nosso trabalho, clique em qualquer banner de sua preferência, exceto dos Parceiros. Mais detalhes clicando aqui.

---

1. Introdução

Instalei o BTRFS por indicação de meu amigo José Rafael no Telegram da Linux Universe. Admito que fiquei na dúvida se seria tão bom quanto ele afirmava, até o momento em que instalei no Thinkpad de uso pessoal e comecei a ver na prática o desempenho e os recursos agregados.

Dentre todos, o mais interessante é o COW (Copy-On-Write) que otimiza o uso de disco e diminui a entrada/saída de dados, ideal para prolongar a vida de SSDs e agilizar o uso de HDDs. Claro, há ressalvas e há casos em que o COW pode dar problemas. Mas isso será abordado mais abaixo.

Comecemos do começo!

2. BTRFS

O BTRFS (B-tree File System, ou Better FS) foi inicialmente desenvolvido pela Oracle Corporation para ser usado no Linux como uma iniciativa concorrente ao então proprietário ZFS. O desenvolvimento do Btrfs começou em 2007, e desde Agosto de 2014, o sistema de arquivos foi marcado como estável.

Seu projeto inicial foi proposto para solucionar problemas como:

• Falta de agrupamento de discos ou volumes
• Snapshots (imagem instantânea do sistema de arquivos)
• Checksums (Soma de verificação)
• Uso de múltiplos volumes simultaneamente nos sistemas de arquivos do Linux.
• Entre outros recursos ausentes, como Compressão e compatibilidade com hardwares de armazenamento modernos como SSD e NVMe.

Nas palavras de Chris Mason, o principal autor do Btrfs, “o objetivo do surgimento do BTRFS foi fazer o Linux ser escalável para a tecnologia de armazenamento que estará disponível no futuro. Escalar não é só lidar com o armazenamento mas também significa ser capaz de administrá-lo e gerenciá-lo com uma interface limpa, que deixa as pessoas verem o que está sendo usado e [assim] torná-lo mais confiável.”

2.1 BTRFS vs ZFS

Dentre os recursos legados que o BTRFS trouxe consigo no kernel Linux 5.0 ou superior, temos, considerando que aqui Online significa que o disco está montado e em uso, enquanto Offline o disco está desmontado:

• Na maioria das vezes se auto-recupera de falhas, em algumas configurações, por causa da natureza da cópia em gravação.
• Desfragmentação online e a opção de montagem autodefrag.
• Aumento e redução do volume, online.
• Adição e remoção de dispositivo de bloco online.
• Balanceamento online
  Permite o movimento de objetos entre dispositivos de bloco para balanceamento de carga de discos, sem necessidade de desmonta-los.
• Verificação do sistema de arquivos offline
  Tal qual EXT4, ainda não é possivel verificar o sistema Online em caso de erros – Um pendrive LiveUSB aqui se faz necessário.
• Verificação de dados on-line para encontrar erros e corrigi-los automaticamente para arquivos com cópias redundantes
  RAID 0, RAID 1,RAID 10
• Subvolumes
  Um ou mais raízes de sistemas de arquivos montáveis separadamente dentro de cada partição de disco.
• Compressão de forma transparente via zlib, LZO e (desde kernel 4.14) ZSTD, configurável por arquivo específico ou volume inteiro.
• Instantâneos de subvolumes somente leitura ou com suporte leitura e gravação atomicamente (via COW)
• Clonagem de arquivo (COW em arquivos individuais) via:
  cp –reflink <aqruivo de origem> <arquivo de destino>
• Somas de verificação em dados e metadados em tempo real de qualquer volume (CRC-32C)
• Conversão local de ext3/4 para Btrfs (com reversão). Esse recurso teve regressões na versão 4.0 da ferramenta btrfs-progs, sendo reescrito do zero na versão 4.6 do kernel Linux.
• Montagem de união de armazenamento somente leitura, conhecida como semeadura de sistema de arquivos, para ser espelhado em sistemas graváveis.
• Descarte de blocos de forma linear (recupera espaço em ambientes virtualizados e melhora o nivelamento da escrita em SSDs/NVMes com TRIM). O Kernel Lnux 5.6 promete trazer suporte a descarte assíncrono, que vai trazer muito mais desempenho aqui!
• Enviar (send)/receber (receive) (salvar diferenças entre instantâneos para um fluxo binário)
• Backup incremental
• Desduplicação de dados fora de banda
  *requer ferramentas de espaço de usuário
• Capacidade de lidar com arquivos SWAP e partições SWAP!
• Suporta Criptografia com EncFS ou TrueCrypt.

Todos estes recursos estão implementados. Porém temos alguns com problemas, cujo uso é desencorajado. Destaco:

• Cotas por subvolume hierarquizadas
  O ideal é utilizar cotas de volumes inteiros caso sejam hierarquizadas.
• RAID 5, RAID 6
  O ideal é utilizar qualquer outro meio de RAID para tal, como o 0, 1, 10, etc.

Ainda temos recursos que não foram adicionados porém estão em fase de planejamento:

• Desduplicação de dados em-banda
• Verificação do sistema de arquivos on-line
• RAID com até seis dispositivos de paridade, superando a confiabilidade do RAID 5 e RAID 6
• RAID 0, RAID 1 e RAID 10 a nível de objeto

Já o ZFS, desenvolvido pela Sun Microsystems, possui o seguinte:

• Proteção contra corrupção de dados
• Suporte para altas capacidades de armazenamento
• Compactação de dados eficiente
• Integração dos conceitos de sistema de arquivos
• Gerenciamento de volume, instantâneos e clones de cópia em gravação (COW),
• Verificação de integridade contínua e reparo automático
• RAID-Z
• ACLs NFSv4

O maior defeito do ZFS é ser inteiramente licenciado como software de código aberto sob a Licença de Desenvolvimento e Distribuição Comum (CDDL), sendo lançado dentro de projetos como o Solaris.

O maior problema aqui, é que a licença CDDL é incompatível com a GPL do Linux de propósito! O conceito da Oracle é de que nada do Solaris deva funcionar, seja a nível de código ou a nível de licenciamento, dentro de um sistema Linux. Devido a isso está surgindo o OpenZFS, mas não vou me ater a detalhes dele, devido á maior maturidade do BTRFS para uso industrial ou domiciliar; e pelo OpenZFS ser mais recente, ainda instável, principalmente em sistemas Ubuntu.

2.1.1 E presta?

Nesse momento você me pergunta:
São muitos recursos, de fato o BTRFS “é tudo isso”?
De forma curta, Sim. É. E a seguir explico os por quês!

Dentre os recursos citados, destaco os mais úteis aos usuários comuns, por serem recursos que não existem no EXT4 e possuem grande utilidade:

• CopyOnWrite (COW)
  Habilitado por padrão, é ideal para HDD’s, SSD’s e NVME’s. Significa que tudo* que o usuário copiar no sistema será imediatamente criado um hard-link, em vez de uma cópia bruta do arquivo. A cópia com isso é instantânea, há menos gravações no SSD e, o segundo arquivo, a cópia, só será alterada caso ajam alterações no arquivo original. Mas há problemas caso implemente em um Banco de Dados SQL: A alta fragmentação do BTRFS pode gerar corrompimentos! Também há uma chance de HDD’s ficarem mais lentos a longo prazo com o COW habilitado. Infelizmente o maior defeito do BTRFS é gerar mais fragmentação que o EXT4 para manter os recursos que possui. Por ser um sistema de arquivos pensado para mídias SSD’s e NVMe’s, fragmentação não é um problema nesses casos.
• Compressão via zlib, LZO e (desde kernel 4.14) ZSTD.
  TODO o sistema de arquivos, desde o conteúdo da raíz até a /home será compactado, o tempo todo, o que economizará espaço em disco! Você pode decidir qual método usar via /etc/fstab e também poderá desabilitar*² caso deseje, para gravar os dados em seu tamanho original.
• Snapshots
  Com o sistema de subvolumes – Quase o que é visto nos LVMs -, o BTRFS permite criar backups incrementais instantâneos do sistema todo, inclusive das partes ativas/montadas! Ele marca um ponto como backup e passa a gravar ao lado apenas as mudanças. Isso cria uma “cópia de sombra” (nos termos do Windows) que é feita em poucos segundos e contém todo o sistema de arquivos e pastas dentro.

* Depende de onde e para onde. As cópias COW funcionam melhor quando gerenciadas dentro do mesmo subvolume e desde que com um gestor de arquivos que dê suporte ao método! – Por sorte a maioria, como o Caja, o Nautilus e o Thunar suportam.

*² Isso só se aplica com arquivos novos, criados após a desativação. Se instalou o Ubuntu antes de configurar o método de compressão, ele vai usar o método padrão; enquanto que, caso mude o método, ele só se aplica aos arquivos criados posteriormente.

Relato pessoal: Economizei quase 10 Gb com o sistema de compressão nativo do btrfs.

2.2 Configurando

Na maioria das distros, no momento da instalação você será perguntado sobre o sistema de arquivos padrão. O Ubuntu por exemplo fornece várias opções, dentre eles XFS, EXT2, EXT3 e EXT4. Inclusive, o BTRFS.

Curiosamente, o BTRFS é jornalado, igual o EXT4.

Um sistema de arquivos jornalado significa que ele mantém um registro a nível de filesystem, do que foi feito, facilitando recuperar qualquer dado em caso de queda de energia e afins. É graças ao Journal que o sistema operacional se recupera sozinho quase 99% das vezes em que há panes elétricas ou de outra natureza. Sem journal, uma corrupção de dados significa quase uma perda total, dificultando recuperar algo.

O Windows utiliza NTFS, que também é Jornalado! Porém a forma como o sistema lida com isso é que deixa a desejar, gerando famigeradas telas azuis da morte em caso de panes severas ás tabelas de partição.

Ao instalar um BTRFS em Ubuntu, teremos 2 diferenciais:

• O BTRFS vai separar a partição raíz em subvolumes @ e @home, caso você não tenha o feito. Isso permite maleabilidade na hora de criar snapshots, ou seja, backups instantâneos do sistema. Mais abaixo explico como criá-los e gerencia-los.
• Será criado um SWAP file porém ele não estará ativo, a menos que o kernel seja o 5.0+! Mais abaixo explico como implementá-lo.

O OpenSUSE, que tem um foco mais no lado empresarial, é mais interessante ainda: Quando instalado, o BTRFS separa TODAS as pastas da raíz / em subvolumes, permitindo uma manutenção granular de todo o sistema em caso de problemas.

3. Usando!

Quando a formatação e instalação terminar, você terá há mão um sistema aparentemente normal.

Logo de cara enquanto você configura seu sistema e volta seus backups, perceberá a compactação do disco – porque o uso de disco vai diminuir drasticamente – e vai notar como funciona o COW na prática – qualquer arquivo repetido dentro do mesmo subvolume vai ser meramente clonado instantaneamente. Esse ultimo caso é ideal para quem gerencia muitas imagens ISO ou mesmo saves de jogos, por exemplo.

3.1 SubVolumes

O BTRFS utiliza uma gerencia de SubVolumes, que são como volumes lógicos dentro da partição, muito semelhante ao sistema visto nos LVM’s (Logical Volume Management). Elas permitem delimitar como e quanto do disco será usado, também tornando prático o manuseio dos snapshots – foi citado logo abaixo.

Não se preocupe: Subvolumes não consomem espaço em disco, apenas é uma subdivisão da partição existente. Dentro da partição / por exemplo poderão haver vários subvolumes como /home dos usuários domésticos e /var em servidores.

Normalmente não há necessidade de fazer grandes alterações nos subvolumes. Mas caso deseje criar um novo subvolume:

$ sudo btrfs subvolume create /caminho/do/subvolume

Deletando um subvolume:

$ sudo btrfs subvolume delete /caminho/do/subvolume

Cuidado para não fazer alterações no subvolume / ou /boot, que pode corromper seu sistema!

Listando todos os subvolumes disponíveis:

$ sudo btrfs subvolume list /

3.1.1 A regra dos níveis

Normalmente quando se instala um sistema com BTRFS, ele gera um subvolume raíz chamado @ (equivale ao / e tem permissões de root) enquanto a partir dalí surgem os demais subvolumes filhos. É uma divisão a nível de sistema de arquivos que geralmente herda permissões do sistema operacional. Somente root pode ler @ enquanto os usuários cadastrados em @home poderão ler a pasta deste subvolume.

Pastas e subvolumes costumam coincidir em caminho e permissão no btrfs.

Ocorre um caso curioso dependendo de como é criado e administrado.

• Se você criar um subvolume filho dentro de outro subvolume pai, como um @subvol dentro de @home, ele será do tipo NESTED.
  Isso significa que ele será auto montado como uma pasta comum no sistema de arquivos, exposto aos usuários que tiverem permissões para vê-lo.
• Se criar um subvolume pai novo, em um disco diferente por exemplo, ele será do tipo FLAT.
  Isso significa que ele será oculto do sistema e deverá obrigatoriamente ser montado manualmente com “mount” no terminal ou com parâmetros dentro de /etc/fstab.

Vantagens e desvantagens do modo FLAT:

• O gerenciamento de snapshots (especialmente rolando-os) pode ser considerado mais fácil, pois o layout eficaz é mais diretamente visível.
• Todos os subvolumes precisam ser montados manualmente (por exemplo, via fstab) nos locais desejados, por exemplo, no exemplo acima, isso se pareceria com:

Vantagens e desvantagens do modo NESTED:

• O gerenciamento de snapshots (especialmente voltar backups) pode ser considerado mais difícil, pois o layout efetivo não é diretamente visível.
• Os subvolumes não precisam ser montados manualmente (ou via fstab) nos locais desejados, eles “aparecem automaticamente” nos respectivos locais.
• Para cada um desses subvolumes, as opções de montagem do ponto de montagem se aplicam.
• Tudo é visível. É claro que só se poderia montar um subvolume, mas partes importantes do sistema de arquivos (neste exemplo, grande parte do sistema de arquivos “principal” do sistema) também estariam ausentes. Isso pode ter desvantagens de segurança, especialmente quando usado com snapshots.

Insira a linha no /etc/fstab sob a seguinte notação:

UUID=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX / btrfs defaults,subvolid=AAA 0 1

Onde os X representam a UUID e o AAA representa o código subvolid.
Para pegar o código subvolid, use:

$ sudo btrfs subvolume list /

Monte com:

$ sudo mount -a

4. Parâmetros

Para quem gosta de customizações, temos algumas opções. A maioria é inserida no /etc/fstab após “defaults” por linha, influenciando diretamente o subvolume montado. Ou seja, se desejar que todo o sistema seja afetado, você deve aplicar os parâmetros que desejar em todas as linhas do /etc/fstab como usuário root. NÃO USE TODOS!

UUID=7244786c-e7af-4591-9eed-eed1b98fad2d / btrfs defaults,ssd, nossd,ssd_spread,noatime,compress=no,nodatacow,space_cache,discard,subvol=@ 0 1

Atentos aos trechos em negrito: Só use os parâmetros que seu sistema requerer ou você julgar necessário. Estão todos na mesma linha apenas para saberem a disposição de cada parâmetro.

4.1 ssd, nossd e ssd_spread

Apesar de óbvio, há sempre uma dúvida sobre o reconhecimento do tipo de mídia em uso pelo sistema linux. Como cada sistema varia nesse reconhecimento, por via das dúvidas, quem utiliza SSD ou SSD NVME pode usar o parâmetro ssd. Ele:

• Permite uma alocação maior de cluster de metadados.
• Aloca dados mais sequencialmente, sempre que possível.
• Desativa a reescrita da folha btree para coincidir com a chave e a ordem de bloqueio.
• Ele confirma fragmentos de log sem agrupar vários processos.

Alguns SSDs apresentam melhor desempenho ao reutilizar números de bloco com frequência, enquanto outros apresentam um desempenho muito melhor quando o cluster aloca estritamente grandes blocos de espaço não utilizado. Por padrão, o comando ssd encontrará grupos de blocos nos quais existem vários blocos livres que podem ter blocos alocados misturados.

Existem SSDs e SSDs, e alguns são de baixa qualidade – geralmente os que tem menos de 400mb/s de leitura e menos de 300mb/s de escrita.

O comando ssd_spread garante que não hajam blocos alocados misturados.

4.2 noatime

Por padrão, o sistema de arquivos é montado com o sinalizador relatime, o que significa que ele deve atualizar os metadados dos arquivos durante o primeiro acesso a cada dia.

Como as atualizações nos metadados são feitas também no COW, se você visitar muitos arquivos, isso resultará em operações de gravação massivas e dispersas na mídia subjacente.

O resultado disso é lentidão no sistema. Use o noatime para poupar escritas desnecessárias de “acessado em” nos arquivos do sistema e em suas cópias! Isso ajuda no desempenho até em HDDs.

4.3 compress=X

O BTRFS sempre compacta os arquivos em disco, independente do volume ou partição, desde que esteja em BTRFS. Suporta os seguintes padrões:

• compress=alg
• compress=zlib
• compress=lzo
• compress=zstd
• compress=no

Este último desliga a compressão. Caso algum arquivo já tenha comprimido, continuará com suporte, não será descomprimido. Sempre use o kernel na versão 5.0 ou superior, para garantir suporte ao zstd caso deseje usa-lo!

Os que oferecem melhor desempenho: zstd e lzo, de acordo com benchmarks.

Dica: Caso use HDD, instale o sistema e configure-o, instalando tudo que você usa ou precisa. Ao final, adicione o parâmetro compress=no para desabilitar a compressão. Isso poupará espaço em disco e deixará o sistema mais rápido.

4.4 nodatacow

Essa opção desabilita o modo COW do subvolume marcado. Lembrando que há uma regra para isso:

• Caso você tenha uma partição dividida em subvolumes, a regra aplicada ao primeiro valerá para os demais. Você só pode ter COW e desabilitar o COW em partições diferentes, nunca em subvolumes diferentes!

Isso foi premeditado para evitar problemas de corrompimento entre os dados dos subvolumes nas alocações dinâmicas.

Além disso, desabilitar o COW só valerá para novos arquivos; os que foram afetados pelo COW continuarão sob COW.

Caso deseje desabilitar o COW para apenas um arquivo específico, use:

$ chattr +C /dir/arquivo

4.5 space_cache

Esse parâmetro ajuda muito a evitar fragmentação: Ele pré aloca espaços em branco para reservas de arquivos, assim o BTRFS trabalha mais próximo do EXT4, evitando fragmentação excessiva. – Mas não elimina a questão, continuará fragmentando com maior frequência que o EXT4.

4.6 discard

Outra opção exclusiva de SSD’s e SSD’s NVME’s.

O parâmetro discard executa, a cada movimento de arquivos na mídia, o comando TRIM. O TRIM é a “desfragmentação” dos SSD’s.

De forma simples, quando você exclui um arquivo no SSD, o gerenciador do circuito integrado dele, simplesmente deixa o espaço liberado como “não usado”. Quando você grava algo e esse espaço tem “lixo”, o SSD erroneamente limpa os transístores, marcando-os como zero, pra depois gravar os dados. Como se preenchesse com zeros um HDD. Isso desgasta ele desnecessariamente a longo prazo.

Com o TRIM, ele marca aquele lote apagado como “removido” e então tudo que chegar depois será apenas gravado por cima; os transístores já ativos continuarão ativos, poupando movimentos de gravação, preservando a saúde dos componentes.

Atentos: Não aconselho o uso do discard, porque ele pode deixar o sistema mais lento, por executar isso o tempo todo a cada mudança nos arquivos. É particularmente ruim para games no WINE/Proton. Para isso, o ideal é executar um fstrim manualmente periodicamente caso movimente muitos arquivos de uma vez: (para todos os sistemas Linux)

$ sudo fstrim -va

5. Snapshot

O Snapshot é com certeza um dos melhores recursos do BTRFS. É semelhante ao Cópia de Sombra do Windows Server, permitindo que você faça um backup instantâneo do sistema com ele ainda em execução!

Basicamente o sistema marca um ponto do disco como “continuação das alterações” enquanto isola todo o restante anterior como somente leitura. As mudanças são acrescentadas separadamente a partir dali, permitindo que, caso necessário, você possa voltar a um estado anterior do sistema. Isso permite backup de qualquer parte, até da partição raiz! Mais simples de aplicar e mais eficiente que um backup grosseiro que copia os arquivos dobrando o espaço consumido em disco.

Dentro do sistema BTRFS, o snapshot não difere estruturalmente, nem a nível de metadados, da estrutura de um subvolume. Então você pode criar snapshots de snapshots!

Cuidado em reverter backups da partição /boot pois você deverá informar ao GRUB como proceder com o boot desses dados que foram isolados.

Snapshots podem ser montados para leitura/escrita a gosto do método usado: Os backups podem ser somente leitura ou permitindo escrita. A montagem é bem semelhante á montagem de uma unidade de disco, logo mais detalharemos sobre isso!

5.1 Criando um Snapshot

Para criar seu primeiro “instantâneo” de um subvolume, faça o seguinte:

# btrfs subvolume snapshot /caminho/do/subvolume /caminho/do/snapshot

O novo Snapshot surgirá no seu sistema com todos os arquivos originais da pasta que foi usada de base. Ele não será montado até que você deliberadamente monte a pasta no seu sistema via comando mount ou via /etc/fstab! Lembre-se de que ele se comporta independentemente do subvolume original, para que você possa fazer o que quiser sem afetar o original. Além disso, o espaço consumido aqui é zero, até que novas mudanças sejam agregadas ao sistema.

Lembra quando falei de problemas com fragmentação? Imagine você ter e gerenciar uns 100 snapshots do mesmo subvolume… Em um HDD esse cruzamento de dados pode causar lentidão. Mas desde 2014 o sistema está estável o suficiente para abarcar tal funcionamento sem problemas.
Excluir snapshots antigos pode ajudar nisso!

DICA: O ideal é ter no máximo 12 snapshots. Acima disso o sistema pode apresentar lentidão característica disso.

Você também pode criar snapshots somente-leitura com o comando:

# btrfs subvolume snapshot -r /caminho/do/subvolume /caminho/do/snapshot

Assim, os dados ali jamais serão alterados, apenas excluídos caso assim o desejar. Poderá ser usado por exemplo como uma base de dados fixa, para ser sempre uma referencia de backup ou ainda uma base default para instalação de outros subvolumes em novas instalações de sistema operacional!

OBS: Snapshots somente leitura NÃO podem ser reutilizados!
Por mais que os snapshots comuns possam ser movidos ou copiados de pasta, o somente leitura só admite ser lido de onde estiver, sob o aspecto de consulta.

Porém, você pode utilizar de um truque do próprio BTRFS: Faça um Snapshot com permissão de escrita, a partir do próprio snapshot somente leitura! Como falei, o BTRFS suporta snapshots de snapshots. Este segundo sim poderá ser movido, editado e utilizado.

5.1.1 Regras

Existem algumas regras diversas quanto a criação de Snapshots. Dentre elas, temos:

• Não existe Snapshot recursivo. Ou seja, um snapshot de um subvolume pai que contenha um subvolume dentro, não vai fazer snapshot do subvolume dentro. Devem ser separados.
  Essa regra veio para evitar conflitos estruturais, enquanto permite maior granularidade da configuração. Portanto atento para a estrutura dos seus subvolumes: Caso ajam subvolumes “abaixo”, dentro de um subvolume maior, estes não terão o backup realizado!
• Limite recomendado de snapshots de qualquer natureza: 12 por partição. Acima disso podem haver problemas estruturais e de fragmentação excessiva, considerando que os 12 snapshots podem ser intercalados/mesclados!
• É obvio mas é bom lembrar: O Snapshot deve ser criado no mesmo volume e disco que os dados originais. Isso é parte fundamental da base COW do BTRFS. Se o backup tiver que ser feito em outro disco de forma íntegra e total, recomenda-se uma ferramenta como o rsnapshot ou mesmo rsync.
• Evite snapshots de partições que possuam qualquer dependência entre si. Por exemplo, as pastas /var, /etc, /bin e /lib possuem muito conteúdo, como links e binários em comum, em seu interior. Portanto isso pode causar corrupções, conflitos ou ainda falhas de segurança.
• Evite fazer uso de snapshots que precisam de propriedades especiais ou pontos de montagem especiais para funcionar.

5.2 Montando um Subvolume ou um backup Snapshot

A montagem de um backup gerado por snapshot segue a mesma proposta da montagem de um subvolume:

$ sudo mount -o subvolid=AAA /dev/sdXY /caminho/da/montagem

Onde AAA é o código ID do subvolume, que pode ser visto com o comando:

$ sudo btrfs subvolume list /

Enquanto XY é o ID do disco que será montado, por exemplo, /dev/SDA1.

5.3 Revertendo para um backup criado

Suponha que você faça uma grande bagunça num subvolume e queira reverter para um snapshot que foi criado anteriormente. Primeiro desmonte o subvolume problemático e depois monte o snapshot em seu lugar seguindo os comandos anteriores.

Lembre-se que se você mexer no /boot, deverá reexecutar o comando do GRUB para que este reconheça o novo subvolume!

$ sudo update-grub2

Se você decidir que não precisa mais do subvolume problemático, poderá excluí-lo e renomear o snapshot com o mesmo nome que o subvolume desconfigurado possuía, para não precisar alterar os arquivos de configuração /etc/stab. Isso agiliza seu trabalho e você poderá recuperar o sistema rapidamente.

Use nosso velho amigo o mv para mover renomeando:

# mv /btrfs/snapshot /btrfs/subvolume

Lembre-se de fazer isso com os subvolumes montados!

5.4 Apagando um Snapshot

A deleção de snapshots é semelhante ao método usado para eliminar subvolumes. Se estiver montado:

# btrfs subvolume delete /caminho/do/subvolume

Se não estiver montado (maioria dos casos):

# btrfs snapshot delete /caminho/do/subvolume

6. SWAP

Para se ter SWAP em BTRFS, o caso é particularmente curioso.

• O SWAP só funciona e só é reconhecido em sistemas com kernel 5.0 ou superior. Para isso, confirme com:
  $ uname -a
  Caso esteja num kernel 4.20 ou inferior, veja aqui como muda-lo!
• Você não pode criar o arquivo SWAP em um snapshot e nem em um subvolume dividido em +1 disco. (caso de empresas).
• O arquivo SWAP não pode ter COW ligado, por razões óbvias: O gerenciamento de despejo de RAM não admite cópia-na-gravação e vai apresentar erros se for montado forçosamente.

Siga estes passos para criar um arquivo SWAP sem COW e como ativá-lo apropriadamente:

• $ touch /swapfile
  Vai criar o arquivo swap em / com 0 bits.
• $ chattr +C swapfile
  Marcará o swap para não ter COW
• $ fallocate –length 1Gib swapfile
  Tamanho do arquivo swap: 1 Gb
• $ sudo chown root swapfile
  Muda a propriedade para o usuário root
• $ sudo chmod 600 swapfile
  Muda a permissão do arquivo para 600 por motivo de segurança
• $ sudo mkswap swapfile
  Adiciona o arquivo swap ao sistema
• $ sudo swapon swapfile
  Ativa o swap no sistema!

Após isso, para que o SWAP funcione, adicione esta linha ao /etc/fstab:

/swapfile none swap sw 0 0

7. Troubleshooting

De todas as dicas, essa é a que mais pode ocorrer:

• Faltou espaço!

Isso ocorre porque o BTRFS usa modos diferentes pra alocar espaço. Ele separa o disco em “chunks”, geralmente o disco todo, e vai usando á medida que a necessidade pedir. Porém pode ser que você fique sem chunks livres, mas com espaço em disco livre. Na verdade, sem chunks = sem espaço.

De uma forma melhor visualizada, nunca mais use o comando “df” caso use BTRFS. Em vez dele, use:

$ sudo btrfs fi usage /ponto/de/montagem

Um exemplo de resultado:

Overall:
Device size: 48.83GiB
Device allocated: 47.80GiB
Device unallocated: 1.03GiB
Device missing: 0.00B
Used: 31.74GiB
Free (estimated): 16.22GiB (min: 16.22GiB)
Data ratio: 1.00
Metadata ratio: 1.00
Global reserve: 89.31MiB (used: 0.00B)

O que nos interessa não é a linha “Free (estimated)”, que aponta 16Gb livres. MAS sim a linha destacada “Device Unallocated”, que é o espaço real. Ou seja, nesse exemplo, se você gravar +1 Gb de dados, o BTRFS ficará lotado e não vai aceitar novos dados.

Como o sistema utiliza Copy-on-Write pra gravar toda e qualquer coisa, não tente desfragmentar o disco! Isso criará novas cópias dos dados que até então tinha apenas links simbólicos, piorando a situação.

Os passos mais apropriados pra prevenir isso, são:

• Apague snapshots antigos.
  Isso também vale para caso você esteja usando o comando “cp –reflink” para criar backups de várias pastas e/ou usuários. Assim você de fato vai liberar espaço em disco.
• Execute o comando BALANCE periodicamente! Mesmo se utilizar SSDs!
  Para produção o ideal é executa-lo com Cron pelo menos 1 a 2x na semana em horários de menor acesso ao disco, porque a operação pode deixar tudo mais lento.

Jamais use o comando -o autodefrag também, porque ele piorará as coisas se for feito um Balance.

Para executar um Balance, use:

$ sudo btrfs balance start  /ponto/de/montagem &

Para corrigir um sistema lotado, tente:

• Apague snapshots mais antigos
• Tente o comando Balance
• Adicione um disco extra para que o BTRFS faça suas operações! Pode ser um pendrive de 4 Gb, é demorado mas suficiente pra ele realocar os dados e liberar espaço.

# Adicione um novo disco (/dev/sdX).
$ sudo mkdir /mnt/disk
$ sudo btrfs device add -f /dev/sdX /mnt/disk
# Agora execute a menor operação de balance possivel:
$ sudo btrfs balance start -dusage=1 /mnt/disk
Done, had to relocate 1 out of 59 chunks
# Remova o dispositivo e execute um novo balance:
$ sudo btrfs device remove /dev/sdX/mnt/disk
$ sudo btrfs balance start -dusage=66 /
Done, had to relocate 18 out of 59 chunks

Caso você esteja num estado de erro de montagem mais grave, siga mais abaixo para o item 7.1.

Estas demais dicas também são pertinentes:

1. Sempre que criar um subvolume, verifique o diretório completo do mesmo.
   Por exemplo, se você criou o subvolume @sub, ele será criado em /home/$USER/@sub. Agora, se criar deliberadamente como /@sub, ele vai ser criado na raíz do sistema numa pasta chamada @sub. Se for excluir o subvolume, aponte o caminho completo! Então use /@sub em vez de apenas @sub.
2. Qualquer dúvida com relação ás ID’s geradas pelo btrfs sempre use o comando:
   $ sudo btrfs subvolume list /.
3. Lembre-se de tomar cuidado quando manipular subvolumes: Apagar o subvolume @ ou @home fará você perder seus dados! Muita atenção aos caminhos e em caso de dúvida: NÃO mexa e garanta que tenha feito seus backups em dia.
4. Apesar de suportar criptografia com o TrueCrypt e EncFS, o BTRFS ainda não suporta criptografia embutida no sistema de arquivos. Portanto atento a isso e, caso necessite de um volume criptografado, dê preferência ao EXT4 devido á maturidade e estabilidade.
5. Caso use o pacote TLP, evite corrompimentos de sistema adicionando o seguinte parâmetro:
   SATA_LINKPWR_ON_BAT=max_performance
6. Se você estiver executando o Bumblebee com o driver NVIDIA, precisará desativar o gerenciamento de energia da GPU no TLP para fazer com que o Bumblebee controle a energia da GPU. Se você estiver executando a versão TLP anterior à 0.9, execute lspci para determinar o endereço da GPU (como 01: 00.0) e defina o valor:
   RUNTIME_PM_BLACKLIST = “01: 00.0”
   Se a sua versão TLP for 1.0 ou superior, defina, de acordo com o driver que você está usando:
   RUNTIME_PM_DRIVER_BLACKLIST = “nova nvidia”
7. Você até pode instalar o BTRFS num disco SEM tabela de partição GPT ou MBR, totalmente limpo! Porém atento que ficará sem poder bootar UEFI e perderá a possibilidade de usar qualquer outro sistema de arquivos no mesmo disco.
8. Você pode converter um sistema que esteja em EXT4 para BTRFS sem necessidade de formatação; mas nós da Linux Universe desencorajamos tal meio, por este ainda estar muito suscetível a falhas. Na dúvida, uma formatação limpa é a melhor escolha.
9. Se precisar de montar um subvolume/snapshot que contenha GRUB, não esqueça de atualiza-lo com: sudo update-grub2

7.1 Em caso de corrompimentos/falhas

É raro, mas pode ocorrer do btrfs corromper em caso de queda de energia. Para isso temos alguns comandos interessantes que devem ser executados sob um disco LiveUSB! BTRFS, tal qual EXT4, não suporta manutenção com os sistemas montados.

1. Tente usar o comando scrub:
   $ sudo btrfs scrub start /mnt/ponto-de-montagem-em-fstab
   O scrub verifica os metadados checksum e restaura os arquivos corrompidos. É o primeiro meio de recuperação, o menos agressivo enquanto é o mais seguro. Ele não admite /dev/sdXY como parâmetro.
   Para visualizar o status do progresso:
   $ sudo btrfs scrub status /mnt/ponto-de-montagem-em-fstab
   Mesmo que a partição não esteja montada e apresente erros de montagem, o btrfs reconhece o caminho pelo UUID no FSTAB.
2. Com o scrub você poderá ter sucesso. Se ainda assim você tiver problemas, monte a árvore root como somente-leitura para acessar seus arquivos de forma segura:
   $ sudo mount -o usebackuproot /dev/sdXY /mnt
3. Uma ultima possibilidade, é caso as árvores dos metadados estejam corrompidos (journal e outros dados sensíveis dos arquivos). Este comando ajuda a reestrutura-los:
   $ sudo btrfs rescue chunk-recover /dev/sdXY
4. Se ainda assim tiver problemas, faça a recuperação dos seus dados de forma mais agressiva, ainda que segura, com o comando restore:
   $ sudo btrfs restore /dev/sdXY /mnt/
   Atento que RESTORE vai pegar os dados da partição danificada e copia-los para outra pasta/partição que estiver Ok.
   Uma versão agressiva e não-segura é com super-recover:
   $ sudo btrfs rescue super-recover /dev/sdXY /mnt/
   Dados podem corromper no processo, calcule o risco pelo benefício.
5. E se no fim você está desesperado porque NADA deu certo, pode tentar o comando check. Estamos acostumados com EXT4 usando check o tempo todo mas no caso do BTRFS, o check fará uma busca bruta que, por mais que sejam casos excepcionais, pode estragar tudo e piorar as coisas na tentativa de recuperar os dados! Use apenas em casos extremos.
   $ sudo btrfs check –repair /dev/sdXY

8. Benchmarks

Há uma injustiça quando o assunto são benchmarks. Quando vemos a maioria das análises, principalmente as do Phoronix, há uma comparação injusta entre EXT4 e BTRFS sem ajustes, ou seja, como se comportam sem qualquer configuração extra.

Obviamente o BTRFS tende a ser mais lento que o EXT4 na maioria dos recursos quando comparado ao EXT4. Porém ele se iguala quando ajustado adequadamente – seja mudando a compressão, ativando parâmetros como space_cache; e outros.

Portanto no presente momento em que essa matéria foi escrita, com testes feitos num Thinkpad X240, não há diferença de tempos de acesso e uso do sistema quando se utiliza BTRFS. Na verdade, para quem utiliza SSD/NVMe, o BTRFS tende a ser mais rápido devido ás otimizações específicas feitas para esse tipo de mídia!

9. RAID

O BTRFS é tão poderoso que pode ser usado para gerenciar todo tipo de RAID – com exceção das 5 e 6 que estão instáveis – em substituição ao já obsoleto mdadm.

No caso eu optei por não citar detalhes do sistema RAID do BTRFS por ele ser mais complexo e exigir uma publicação dedicada, que logo publicarei aqui na Linux Universe!

10. Conclusão

Com uma porção de novos recursos de otimização, desempenho, manuseio e recuperação de dados, o BTRFS se torna uma opção interessante de um sistema de arquivos moderno adaptado ás novas tecnologias!

Por mais que o EXT4 tenha maturidade e tenha ganhado muitos recursos nos últimos anos – dentre eles as opções de TRIM em SSDs – o BTRFS trouxe opções legadas que eram até então exclusivas do Windows Server, para as mãos dos usuários comuns.

Claro que a curva de aprendizagem é maior, há mais comandos e uma nova sintaxe de hierarquias a ser aprendida, mas a mudança é sempre bem vinda e não perdemos nada em aprender um pouco mais!

#UrbanCompassPony

Fontes:
ohthehugemanatee
Phoronix
ArchWiki
RedHat
linux.com
cloudnull.io
ownyourbits