Olá a todos,

Como é conhecido de quem lê o meu blog, faço uso de vários tipos de filesystems nos meus sistemas Linux.
Desde XFS a BTRFS, passando por Ext4 e ZFS, cada um brilha na sua utilização especifica.
Hoje venho falar de BTRFS que uso em máquinas que dão suporte a containers devido ao backend support de LXC a este filesystem e a capacidade de SSD caching a discos mecânicos.

Long story short, um dos meus servidores de LXC/containers, quando falhou a energia elétrica, não recebeu – ou escolheu não receber – a ordem de shutdown da UPS quando a energia em reserva chegou a níveis críticos.
O resultado do shutdown não ordenado, foi uma máquina onde um dos  volume de BTRFS não montava, com o erro de parent transid verify failed.

Este erro, ocorre quando temos uma transação de write ou delete presa no journaling do sistema operativo, e o disco (ou volume) onde está a tentar escrever não corresponde a topologia de dados que esperava.
A consequência? Não montar os filesystems e consequentemente não ter acesso aos dados lá incluídos.

No meu caso especifico, o erro era este:

parent transid verify failed on 3139939436512 wanted 162425 found 162256

Existem várias formas de resolver o tema, mas *todas* passam por ter backups válidos do filesystem ou volume em questão.

Nota: Caso não tenham backups válidos, existe forma de retirar do volume danificado os dados, através de opções de mount:

mount -t btrfs -o ro,rootflags=recovery,nospace_cache /dev/vglxc/lxc /mnt/tmp
mount -t btrfs -o ro,rootflags=recovery,nospace_cache,clear_cache /dev/vglxc/lxc /mnt/tmp
mount -t btrfs -o ro,recovery,nospace_cache,nospace_cache /dev/vglxc/lxc /mnt/tmp

Em seguida copiem os vossos dados para uma outra localização antes de proceder a reparação do volume de btrfs.

Atenção que o método acima pode falhar. Para estes casos, é tentar um btrfs restore:

btrfs restore /dev/vglxc/lxc /mnt/tmp

Nota:  Este método vai demorar, pelo que é aconselhado correr ele numa consola que esteja em TMUX ou Screen.

Finalmente iremos então recuperar o volume:

umount /dev/vglxc/lxc
btrfsck --repair /dev/vglxc/lxc

Sei de ocasiões em que mesmo assim, após o btrfsck, em que o volume teima em não montar.
Nestas alturas, e em ultimo recurso, pode-se efetuar os seguintes comandos:

btrfsck --init-extent-tree /dev/vglxc/lxc
btrfs-zero-log /dev/vglxc/lxc

É importante ter noção que a partir do momento em que corram os comandos imediatamente acima ficam com possíveis corrupções em ficheiros, pois as transações que estavam pendentes em journaling acabaram de ser purgadas, portanto é fundamental manter *sempre* backups dos vossos dados.

No meu caso, foram apenas ficheiros de logs dos containers que estavam a ser escritos no momento da falha energética que sofreram danos, pelo que não necessitei de nenhum restore.

Concluindo,

Embora não seja um ZFS, o BTRFS é um filesystem extremamente promissor e extremamente potente.
É contudo igualmente extremamente sensível a power’s down a bruta, ou descontrolados.

A reter desta historia? Tenham sempre os vossos backups em dia (coisa que faço religiosamente), e comprem uma UPS.
Se vou mudar para outro filesystem? Não. Mesmo com a Redhat a colocar este filesystem em deprecated – na minha opinião esta atitude tem motivação comercial e não de engenharia do produto.
Este apresenta muitas vantagens em relação aos outros para a utilidade que lhe dou.

Até a um próximo post!

Abraço!
Nuno