Captura instantânea LVM do dispositivo montado de mudanças de volume btrfs

Question

Eu tenho um volume btrf no topo do LVM. Agora eu quero fazer um snapshot no nível lvm (NÃO no nível btrfs). Mas toda vez que eu crio o snapshot do LVM, o btrfs muda o dispositivo de bloco montado para o snapshot como se eu estivesse usando algum tipo de opção de montagem --bind.

Situação:

# mount | grep libvirt
/dev/dm-4 on /var/lib/libvirt/images type btrfs (rw,relatime,space_cache)
# ls -l /dev/mapper | grep dm-4
lrwxrwxrwx 1 root root       7 Mär 17 01:18 system-vm_disks -> ../dm-4
# lvcreate -s /dev/system/vm_disks -n vm_backup -L 32G
  Logical volume "vm_backup" created
# mount | grep libvirt
/dev/dm-5 on /var/lib/libvirt/images type btrfs (rw,relatime,space_cache)
# ls -l /dev/mapper | grep dm-5
lrwxrwxrwx 1 root root       7 Mär 17 01:18 system-vm_backup -> ../dm-5
# mount /dev/system/vm_backup /mnt/test
# touch /mnt/test/touchME
# ls -l /var/lib/libvirt/images/touchME
-rw-r--r-- 1 root root 0 Mär 17 01:26 /var/lib/libvirt/images/touchME

Quando eu removo o instantâneo:

# umount /mnt/test
# lvremove /dev/system/vm_backup 
Do you really want to remove active logical volume vm_backup? [y/n]: y
  Logical volume "vm_backup" successfully removed
# mount | grep libvirt
/dev/dm-4 on /var/lib/libvirt/images type btrfs (rw,relatime,space_cache)
# ls -l /dev/mapper | grep dm-4
lrwxrwxrwx 1 root root       7 Mär 17 01:21 system-vm_disks -> ../dm-4
# ls -l /var/lib/libvirt/images/touchME
-rw-r--r-- 1 root root 0 Mär 17 01:26 /var/lib/libvirt/images/touchME

Espero que meu instantâneo seja um instantâneo real e não algo como uma montagem --bind. Estou usando os instantâneos do LVM para fazer backup de um estado de sistema consistente via rsync para o nosso servidor de backup. E eu não quero usar instantâneos do btrfs por vários motivos:

• Desejo fazer backup de todos os subvolumes e todos os instantâneos do btrfs dentro do vm_disks LV (e não sei quanto e quais snapshots / subvolumes existem)
• Minha estratégia de backup não deve ser dependente do sistema de arquivos. O ideal é que não seja necessário alterar mais nada ao alterar o sistema de arquivos em / var / lib / libvirt / images

Meu sistema:

# uname -a
Linux laptop 3.12-1-amd64 #1 SMP Debian 3.12.9-1 (2014-02-01) x86_64 GNU/Linux
# lvm version
  LVM version:     2.02.104(2) (2013-11-13)
  Library version: 1.02.83 (2013-11-13)
  Driver version:  4.26.0
# btrfs --version
Btrfs v3.12

Eu tenho que usar pelo menos o kernel 3.9 ou mais recente, já que eu uso os recursos IPv6 NAT fornecidos pelo Linux 3.9 ou mais recente (sim, eu sei que você não deve usar NAT com IPv6, mas isso é outra história).

Obrigado pela sua ajuda!

Editar:

Eu fiz alguns experimentos usando dispositivos dd e loop. Este comportamento não é específico para o LVM.

Testes:

# mkfs.btrfs /dev/loop0
[...]
# mount /dev/loop0 original
# touch original/original_file
# ls -l original
-rw-r--r-- 1 root root 0 Mar 28 21:42 original_file
# dd if=/dev/loop0 of=/dev/loop1
509312+0 records in
509312+0 records out
260767744 bytes (261 MB) copied, 1.76431 s, 148 MB/s
# mount /dev/loop1 clone
# touch clone/expected_clone_file
# ls -l clone
-rw-r--r-- 1 root root 0 Mar 28 21:44 expected_clone_file
-rw-r--r-- 1 root root 0 Mar 28 21:42 original_file
# ls -l original
-rw-r--r-- 1 root root 0 Mar 28 21:44 expected_clone_file
-rw-r--r-- 1 root root 0 Mar 28 21:42 original_file
# umount clone
# umount original
# mount /dev/loop1 clone
# ls -l clone
-rw-r--r-- 1 root root 0 Mar 28 21:42 original_file
# umount clone
# mount /dev/loop0 original
# ls -l original
-rw-r--r-- 1 root root 0 Mar 28 21:44 expected_clone_file
-rw-r--r-- 1 root root 0 Mar 28 21:42 original_file

Portanto, sempre que você tentar montar um novo dispositivo com um sistema de arquivos btrfs clonado, acabará usando o dispositivo já montado (mas nada na saída da montagem está indicando isso corretamente, como você pode ver na experiência do LVM acima) . Todos os pedidos acabam usando o dispositivo antigo. Você não é capaz de montar o fs clonado até desmontar o fs original (e não pode montar o fs original enquanto o clonado estiver montado).

Minha pergunta agora é: Como posso alterar o uuid do btrfs clonado para algum novo uuid não utilizado. Depois disso, eu seria capaz de montar o dispositivo clonado ao lado do original, suspeito.

    

Answer 1

Eu não olhei muito para isso, mas o btrfs como um sistema de arquivos funciona em grupos de discos, não em dispositivos individuais.

Eu suspeito que não há como o btrfs distinguir entre o snapshot montado e o sistema de arquivos real montado quando ocorre uma montagem. Pode, de fato, ver o UUID do subvolume subjacente, assumir que é um espelho do volume original e escrever nos dois volumes ao mesmo tempo.

Eu ficaria surpreso se isso fosse consertado já que, para a maioria das intenções e propósitos, os snapshots do btrfs substituem os snapshots do LVM.

    

Answer 2

Parece que o udev está causando esse comportamento.

Realizar o lvcreate (ou losetup) faz com que o udev "altere" as ações no sistema "block":

# udevadm monitor
...
UDEV  [62084.032411] change   /devices/virtual/block/dm-7 (block)
UDEV  [62084.469374] change   /devices/virtual/block/dm-6 (block)
UDEV  [62084.582549] change   /devices/virtual/block/dm-6 (block)
UDEV  [62084.606191] change   /devices/virtual/block/dm-5 (block)
...

que aciona (no meu caso) as regras de

/lib/udev/rules.d/64-btrfs.rules

e chama o comando interno do udev:

IMPORT{builtin}="btrfs ready $devnode"

que passa por src / udev / udev-builtin-btrfs.c: 52

err = ioctl(fd, BTRFS_IOC_DEVICES_READY, &args);

Para pousar no kernel em: link causando um dmesg como:

...
[62030.117248] btrfs: device label label devid 1 transid 13 /dev/dm-6
[62030.141242] btrfs: device label label devid 1 transid 13 /dev/dm-5
...

Não está claro exatamente o que está causando o "remount" ou porque é necessário. Mas as observações que o UUID duplicado é responsável não parecem improváveis.

Eu nem tenho certeza se esse tipo de remontagem (mudar o dispositivo do ponto de montagem existente) é um comportamento desejado ou útil ...

Se você quiser alterar o comportamento, você pode modificar ou remover as regras do btrfs-udev com perda de funcionalidade: não há mais montagens automáticas após o hot-plug dos discos usb do btrfs.