Eu deveria estar preocupado? Segfaults relatados no syslog ao mesclar o instantâneo do LVM (revertendo o original de volta ao instantâneo)

Question

Eu estava experimentando snapshots no LVM no Ubuntu 12.10. Criei um volume lógico de snapshot de 6,5 GiB e, depois de fazer algumas alterações na origem, decidi mesclar o snapshot novamente para desfazê-las. Tudo parecia estar indo bem, mas notei várias mensagens de falha de segurança relacionadas ao LVM no syslog.

Comandos inseridos:

sudo lvcreate -L6.5G -n backup_snapshot -s /dev/mapper/vg0-backup
# made some miscellaneous writes
sudo lvconvert --merge /dev/vg0/backup_snapshot
sudo umount /snapshot/backup
sudo umount /backup
sudo lvchange -an /dev/vg0/backup
sudo lvchange -ay /dev/vg0/backup
sudo mount /backup

Do syslog:

Apr 12 04:57:10 bournemouth kernel: [ 5260.813253] EXT4-fs (dm-1): mounted filesystem with ordered data mode. Opts: errors=remount-ro
Apr 12 05:00:11 bournemouth kernel: [ 5441.841401] EXT4-fs (dm-5): mounted filesystem with ordered data mode. Opts: errors=remount-ro
Apr 12 05:02:00 bournemouth kernel: [ 5551.438487] show_signal_msg: 48 callbacks suppressed
Apr 12 05:02:00 bournemouth kernel: [ 5551.438495] lvm[5813]: segfault at 28 ip 000000000047f319 sp 00007fff60873de0 error 4 in lvm[400000+d9000]
Apr 12 05:02:01 bournemouth kernel: [ 5552.458797] lvchange[6449]: segfault at 28 ip 000000000047f319 sp 00007fff935f4380 error 4 in lvm[400000+d9000]

Em seguida, desmontei o LV de origem, certifiquei-me de que o instantâneo não existia mais e executei fsck.ext4 -f-o; deu certo dessa forma. Mas ainda estou preocupado com as falhas de segurança. É possível que meus dados tenham sido confusos de alguma forma que o fsck não detectou? O volume que eu estava experimentando era um backup, e todos os sistemas de arquivos dos quais fiz backup ainda estão funcionando, então eu poderia simplesmente começar de novo e fazer backup deles novamente. Mas, por outro lado, gostaria de manter meu histórico de backup incremental. Gostaria apenas de ter certeza de que posso confiar nesses backups.

Answer 1

Sim, é definitivamente um bug, mas não se preocupe, o LVM é inteligente o suficiente para lidar com essas coisas, uma vez faltou energia no meio de um pvmove e tudo que tive que fazer foi basicamente ligar o servidor novamente "cancelar" o antigo pvmove e reiniciá-lo.

Primeiramente, é importante saber que as ferramentas que você usa são apenas uma interface de espaço de usuário para processos do kernel. O LVM vive dentro do kernel, então, a menos que seu kernel entre em pânico, você está bem. As ferramentas de espaço do usuário, como pvmove ou lvchange, apenas fazem interface com o LVM para nós e depois relaxam e basicamente perguntam ao kernel "Ei, você já terminou isso? Como ficou?" ou "Ei, até que ponto estamos nisso?" (Seu problema específico é com a falha de segmentação do lvchange após a conclusão bem-sucedida do lvchange,parece um bug corrigido recentementeentão você pode querer ter certeza de ter todas as atualizações do sistema).

Como um ponto geral, você também não deve ser tão desajeitado ou paranóico sobre se está com problemas com o LVM, ele foi projetado para lidar bem com erros inesperados como esse (mesmo quando eles afetam diretamente e não apenas a ferramenta que você está usando ) e essa garantia faz parte do uso de um gerenciador de volume em vez de partições tradicionais. Você só está em apuros se algorealmentealgo ruim acontece ou você faz algo sem pensar bem. O LVM opera por extensões (em vez de blocos) e não torna a extensão copiada ativa e a original inativa até que a operação de cópia já seja concluída com sucesso. Ao fazer isso, as extensões parcialmente copiadas permanecerão marcadas como não alocadas e quaisquer ferramentas subsequentes apenas escreverão sobre elas. Este é o caso do meu pvmove e do seu lvchange.

EDITAR:

Olhando paraeste anúncio da lista de discussão, podemos obter uma descrição mais detalhada de como sua mesclagem realmente funciona "nos bastidores":

Enquanto a mesclagem estiver ativa, qualquer acesso ao dispositivo de origem será [direcionado para] o instantâneo que está sendo mesclado. Quando a mesclagem termina, o destino de origem é recarregado perfeitamente e o instantâneo da mesclagem é descartado. O sistema de arquivos [não instantâneo] pode permanecer montado durante esse tempo.

Achei que seria interessante saber

Answer 2

Embora o trabalho pesado seja tratado pelo kernel (mapeador de dispositivos), seus dados como tais devem estar seguros. No entanto, as ferramentas de usuário do LVM ainda possuem funções importantes; eles mantêm os metadados do LVM, o que está armazenado, onde e como, que o próprio mapeador de dispositivos não conhece nem se importa.

Se a ferramenta LVM falhar no meio da atualização de tais metadados, é possível sofrer perda de dados. De certa forma, o LVM é um sistema de arquivos para partições; metadados LVM danificados equivaleriam à perda de um superbloco do sistema de arquivos. É por isso que quase todas as alterações são registradas/copiadas em /etc/lvm/....

Segfaults nunca são bons - se suas ferramentas LVM fazem isso, você deve parar de usá-las e mudar para uma versão LVM que funcione de forma estável para você. E provavelmente reporte um bug à sua distribuição, para que o problema possa ser rastreado e corrigido para sempre.