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 subvolumes 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
Siga estas instruções caso tenha problemas lidando com o BTRFS, seus subvolumes ou mesmo
os snapshots:

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 subvolumes 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:
Phoronix
ArchWiki
RedHat
linux.com
cloudnull.io
ownyourbits