Btrfs no openSUSE - Subvolumes misteriosos





O openSUSE já usa o btrfs como sistema de arquivos padrão desde a versão 13.2, quer dizer desde novembro de 2014. Pessoalmente instalei o btrfs no meu teste da versão 12.3 e nunca tive problemas com esta decisão. A regra que segui é usar o dobro do tamanho normal para a partição root, mas pelo menos 25 GB. Na época a teoria não me interessava. Só posso dizer que o desempenho foi razoável também no notebook velho ASUS que comprei em 2009. A necessidade de um fazer um rollback só surgiu no início do ano passado.

Pessoal este artigo e uma contribuição do Ulrich Beckmann aka Bequimão um colaborador muito atuante não só dentro da comunidade openSUSE bem como na comunidade Mageia do Brasil.



Em principio o btrfs oferece as mesmas funções como o Logical Volume Manager (LVM). Destacam os snapshots - a possibilidade de regressar a um estado do sistema de arquivos anterior - e aumentar o sistema de arquivos quando estiver online. Enquanto o LVM fica lento em transações grandes, não se sente nenhuma diferença no btrfs. Então se pode dizer que sistema de arquivos btrfs é bastante otimizado.


Para ter uma ideia das possibilidades deste sistema de arquivos acho bem fazer alguns exercícios com os seus dedos no terminal:

https://www.linux.com/learn/how-manage- ... nux-part-1
https://www.linux.com/learn/how-create- ... nux-part-2


Infelizmente estas dicas são escritas em Inglês.


O openSUSE usa um sistema particular com vários subvolumes predefinidos, a ver no meu sistema atual:


# btrfs subvolume list /
ID 257 gen 208902 top level 5 path @
ID 258 gen 209655 top level 257 path @/.snapshots
ID 260 gen 208906 top level 257 path @/boot/grub2/i386-pc
ID 261 gen 209280 top level 257 path @/boot/grub2/x86_64-efi
ID 263 gen 209376 top level 257 path @/opt
ID 264 gen 208911 top level 257 path @/srv
ID 265 gen 209655 top level 257 path @/tmp
ID 266 gen 209486 top level 257 path @/usr/local
ID 267 gen 208917 top level 257 path @/var/crash
ID 268 gen 208919 top level 257 path @/var/lib/libvirt/images
ID 269 gen 208921 top level 257 path @/var/lib/mailman
ID 270 gen 208923 top level 257 path @/var/lib/mariadb
ID 271 gen 208925 top level 257 path @/var/lib/mysql
ID 272 gen 208927 top level 257 path @/var/lib/named
ID 273 gen 208929 top level 257 path @/var/lib/pgsql
ID 274 gen 209662 top level 257 path @/var/log
ID 275 gen 208933 top level 257 path @/var/opt
ID 276 gen 209664 top level 257 path @/var/spool
ID 277 gen 209659 top level 257 path @/var/tmp
ID 2131 gen 209664 top level 258 path @/.snapshots/d4/new_def_1426
ID 2175 gen 208939 top level 2131 path var/lib/machines
ID 2219 gen 209655 top level 257 path @/var/cache
ID 2525 gen 207207 top level 258 path @/.snapshots/1699/snapshot
ID 2528 gen 207230 top level 258 path @/.snapshots/1701/snapshot
ID 2529 gen 207292 top level 258 path @/.snapshots/1702/snapshot
ID 2530 gen 208237 top level 258 path @/.snapshots/1703/snapshot
ID 2531 gen 208251 top level 258 path @/.snapshots/1704/snapshot
ID 2532 gen 208851 top level 258 path @/.snapshots/1705/snapshot
ID 2534 gen 208872 top level 258 path @/.snapshots/1706/snapshot
ID 2536 gen 209245 top level 258 path @/.snapshots/1708/snapshot
ID 2537 gen 209482 top level 258 path @/.snapshots/1709/snapshot
ID 2538 gen 209491 top level 258 path @/.snapshots/1710/snapshot
linux-91w7:~ #



O sistema de arquivos é organizado em subvolumes, que podem ser montados na árvore de diretórios da mesma maneira como as partições. Os dois comandos seguintes tem um efeito idêntico:


# mount /dev/mapper/vg1-mlvm12 -o subvol=@ /mnt
# mount /dev/mapper/vg1-mlvm12 -o subvolid=5 /mnt



O subvolume número 5 é o subvolume raiz que nunca pode ser excluído.


A peculiaridade do openSUSE é que o subvolume padrão que representa o root difere do subvolume raiz. O subvolume padrão é o que é montado no sistema de arquivos pelo comando mount sem subvolumes opcionais.

linux-91w7:~ # btrfs subvolume get-default /
ID 2131 gen 209674 top level 258 path @/.snapshots/d4/new_def_1426
linux-91w7:~ #



No início o subvolume padrão é o @/.snapshots/1/snapshot. Modifiquei isto no meu sistema manualmente por um rollback.


Por que esta variedade de subvolumes?
Os snapshots do btrfs funcionam no nível dos subvolumes.
Como exemplo o comando:



# btrfs subvolumes snapshot -r / /.snapshots/'pre atualização 15.03.'
cria um snapshot somente leitura do subvolume montado em /, que dizer do subvolume padrão ID 2131. A partir deste momento todas as modificações serão salvados separadamente, ou ainda somente os blocos modificados serão salvados. Este mecanismo chama-se em Inglês Copy-on-Write com a sigla COW.



Agora por que tantas exceções?


- No caso do @/home é claro. Se for preciso um rollback, não queremos perder os dados recentes dos usuários. Como consequência, o btrfs não livra o usuário da necessidade de fazer backup. Lembramos ainda que há a possibilidade de quebras de hardware. Exclui o subvolume @/home, já que uso uma partição separada e criptografada para /home.


- Depois de uma falha do sistema e um rollback do sistema de arquivos root queremos continuar o trabalho imediatamente, mas os logs sob /var/log tem que ficar para uma análise posterior da falha.


- Pastas e dados temporários serão perdidos em qualquer caso. Armazená-los seria um desgaste de espaço e performance.


- Pastas que referem a bancos de dados como o MySQL. Os bancos de dados em geral tem seus próprios mecanismos de backup e rollback, e também otimizações próprias. Ali ficam as os binários, configurações e arquivos de administração. Fazer um rollback significaria uma inconsistência entre os dados uteis e os dados de gerenciamento. Uma inconsistência fatal na majoria dos casos. Mais ainda, um rollback pode resultar em um downgrade de versão do banco de dados. Upgrades são testados, downgrades quase nunca. Outra vez inconsistências.


- Os arquivos binários do grub tem que ficar alinhados aos blocos do disco rígido e sem fragmentações (em Ingles aligned and contiguos). Lembramos que o mecanismo COW sempre resulta em fragmentações dos arquivos. Neste caso o sistema não vai mais dar boot!


(N.B. o comando grub2-install deve tomar previdência de que os binários não sejam fragmentados mediante atributos apropriados.)


Em resumo, esta variedade de subvolumes é muito bem planejada pelos desenvolvedores do openSUSE.


Este artigo é um resultado de minha experiência de ponto de um usuário, e não de um desenvolvedor, provavelmente especulativo e pode ter erros. Não escrevi para um iniciante no openSUSE. Perguntas e uma discussão são bem-vindos.

Bequimão, mais uma vez, muito obrigado pela contribuição, tenho certeza que contribuiu muito para o conhecimento dos usuários sobre sobre o tema.