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

Question

Eu estava apenas experimentando snapshots no LVM no Ubuntu 12.10. Eu criei um volume lógico de instantâneo de 6,5 GiB e depois de fazer algumas alterações na origem decidi mesclar o instantâneo novamente para desfazê-las. Tudo parecia estar indo bem, mas notei várias mensagens de segfault 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]

Eu então desmontei o LV de origem, certifiquei-me de que o instantâneo não existia mais e executei fsck.ext4 -f nele; deu certo OK assim. Mas ainda estou preocupado com os segfaults. É possível que meus dados fiquem confusos de alguma forma que o fsck não entenderia? O volume que eu estava experimentando era um backup, e todos os sistemas de arquivos que eu copiei nele ainda estão em funcionamento, então eu poderia começar de novo e fazer backup deles novamente. Mas, por outro lado, gostaria de manter meu histórico de backup incremental. Eu gostaria 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 eu tive o poder de sair no meio de um pvmove e tudo o que eu tinha que fazer era basicamente ligar o servidor novamente "cancelar" o antigo pvmove e iniciá-lo novamente.

Primeiro, é importante saber que as ferramentas que você usa são apenas uma interface de espaço do 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 a interface com o LVM para nós e, em seguida, apenas relaxam e basicamente perguntam ao kernel: "Ei, você já fez isso? Como foi?" ou "Ei, até onde estamos com isso?" (Seu problema específico é com o lfchange segfaulting após a conclusão bem-sucedida da lvchange, soa como um bug recentemente corrigido para que você possa quero ter certeza de que você tem todas as atualizações do seu sistema).

Como ponto geral, você também não deve ser tão esquisito ou paranóico sobre se você está com problemas com o LVM, ele é projetado para lidar com erros inesperados como este bem (mesmo quando eles impactam diretamente e não apenas a ferramenta que você está usando) e essa garantia faz parte do ponto de usar um gerenciador de volume em partições tradicionais. Você só está com problemas se algo realmente ruim acontece ou você faz alguma coisa sem pensar. 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á esteja concluída com êxito. Ao fazer isso, as extensões parcialmente copiadas permanecerão marcadas como não alocadas e todas as ferramentas subsequentes serão escritas sobre elas. Este é o caso do meu pvmove e do seu lvchange.

EDITAR:

Analisando este anúncio da lista de discussão , podemos obter uma descrição mais detalhada de como sua mesclagem realmente funciona "sob o capô ":

While the merging is active, any accesses to the origin device are [directed to] the snapshot that is being merged. When the merging finishes, the origin target is seamlessly reloaded and the merging snapshot is dropped. The [non-snapshot] filesystem can stay mounted during this time.

Achei que seria interessante saber

    

Answer 2

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

Se a ferramenta LVM se fragmentar 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 equivalem à perda de um superbloco de sistema de arquivos. É por isso que quase todas as alterações são registradas em log / backup em /etc/lvm/... .

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