lvremove reivindicações LV para ser aberto

Question

frequentemente noto que depois de um

$ sudo lvcreate vg -L 10G

imediatamente seguido por um

$ sudo lvremove vg/<created volume>

Eu recebo a mensagem de erro

Não é possível remover o volume lógico aberto "..."

enquanto um

$ sudo lvs

mostra-me para esse volume

  lvol2         vg   -wi-a-  10,00g

• então, há um - após o a nos sinalizadores, onde deveria haver um o se o volume estivesse realmente aberto.

Depois de algum tempo, a exclusão funciona.

Por que esse é o caso? Como posso fazer isso funcionar imediatamente?

EDIT: O seguinte não levou a algo útil:

$ sudo rm /dev/mapper/vg-lvol24 
$ sudo lvremove /dev/vg/lvol24
  Can't remove open logical volume "lvol24"
$ sudo lvs vg/lvol24
  LV     VG   Attr   LSize  Origin Snap%  Move Log Copy%  Convert
  lvol24 vg   -wi-a- 10,00g                                      
$ sudo lvremove /dev/vg/lvol24
  Can't remove open logical volume "lvol24"

    

Answer 1

Parece que há um problema com a cooperação entre o lvm e o udev.

Em um lvremove , há udev eventos de alteração para cada dispositivo de bloco disponível. Seu processamento parece perturbar o processo de remoção e a remoção falha.

A solução é desativar o (s) LV (s) a ser removido com lvchange -an <given LV> . Nesse caso, apenas alguns eventos "remover" são criados, o que resulta da remoção do dispositivo dm associado.

Se eu lvremove o agora desativado LV, ainda há muitos eventos de mudança do udev, mas eles não afetam o LV a ser removido (porque ele não existe mais no dm), então funciona sem problemas.

    

Answer 2

Portanto, há outra possibilidade além do NFS, do processo bash obsoleto e do mau comportamento do udev, ou seja, partições abertas no dispositivo de bloco.

kpartx -d /dev/vg1/lv1

Em seguida, você pode verificar que # open cai para 0 na saída de lvdisplay .

    

Answer 3

Remova todos os mapeamentos para esse LV de / dev / mapper / excluindo os links simbólicos e, em seguida, você poderá removê-lo.

    

Answer 4

Alguns comandos úteis para descobrir se algo ainda está usando um disco:

cat /proc/mounts
dmsetup ls --tree
lsof <device>

    

Answer 5

Eu me deparei com um problema semelhante com uma instalação do OpenStack. lsof não mostrou nada para mim, mas dmsetup ls --tree mostrou uma dependência / meta. lvchange -an <given LV> não funcionou para mim também. Nem deletou links simbólicos para os /dev/dm-* devices

No meu caso, encerrei os serviços do OpenStack e, em seguida, consegui lvremove dos volumes recalcitrantes.

Esta é uma configuração experimental, e acho que posso ter causado o problema inicialmente por uma reinicialização forçada que fiz para resolver alguns outros problemas.

    

Answer 6

Eu também recebi este erro. Felizmente, eu estava em uma fase inicial de construção, sem dados a perder. Devo observar que o volume lógico acabara de ser criado na última meia hora.

Para permitir a remoção do volume lógico, executei o seguinte:

1. (No fdisk) Exclua a partição de tabela que eu criei para esse volume lógico.
2. (No fdisk) Efetuou uma gravação - depois de confirmar que não existiam partições de tabela
3. partprobe
4. multipath -F (libera dispositivos multi-caminho não utilizados)
5. serviço multipathd stop
6. serviço multipathd start
7. reinicialize o servidor
8. lvscan quando o servidor voltou a funcionar
9. lvremove

Answer 7

Eu encontrei isso recentemente. Eu esqueci completamente que o dispositivo XYZ era um volume luks, mapeado para XYZ e que o lvm subjacente estava realmente em uso pelo mapa do luks.