Tema: btrfs
-
Verificação e reparo de sistemas de arquivos: fsck, xfs_repair e btrfs check em um sistema de arquivos desmontado
ext4, XFS e Btrfs têm cada um o seu próprio verificador, com regras de segurança diferentes: e2fsck e xfs_repair devem ser executados em um sistema de arquivos desmontado (xfs_repair tem o modo de simulação -n), enquanto btrfs check é somente leitura por padrão e desaconselha fortemente o uso de --repair. Quem decide se um reparo é necessário são os códigos de saída e o resultado da simulação, não a intuição.
-
Snapshots Btrfs e rollback com snapper no SUSE: pares pre/post, boot pelo GRUB e limpeza
Em uma raiz Btrfs, o snapper do SUSE cria um par de snapshots pre/post em torno de cada alteração feita pelo zypper ou pelo YaST, lista-os com `snapper list` e permite reverter o sistema inteiro ou dar boot direto em um snapshot antigo pelo menu do GRUB. Os snapshots antigos são removidos automaticamente, mas quem define quanto histórico é mantido é a política de limpeza, e não só o tamanho do disco.
-
Atualizações transacionais no SUSE Linux Micro, openSUSE MicroOS e Leap Micro: raiz somente leitura e ativação por reinicialização
Nos produtos SUSE com raiz imutável, o transactional-update instala as alterações em um novo snapshot de um sistema de arquivos somente leitura, sem tocar no sistema em execução; nada entra em vigor até que uma reinicialização ative esse snapshot, e uma atualização com problemas é desfeita com rollback, não com downgrade de pacotes. No SLES convencional o mesmo mecanismo existe, mas é documentado como technology preview para uma raiz somente leitura, e não como padrão.
Legível por máquina: JSON