Назад | Перейти на главную страницу

Снимок LVM изменения тома btrfs смонтированного устройства

У меня есть том btrf поверх LVM. Теперь я хочу сделать снимок на уровне lvm (НЕ на уровне btrfs). Но каждый раз, когда я создаю снимок LVM, btrfs меняет смонтированное блочное устройство на снимок, как будто я использовал какую-то опцию --bind mount.

Ситуация:

# 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

Когда снимаю снимок:

# 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

Я ожидаю, что мой снимок будет настоящим снимком, а не чем-то вроде монтирования --bind. Я использую моментальные снимки LVM для резервного копирования согласованного состояния системы через rsync на наш сервер резервного копирования. И я не хочу использовать снимки btrfs по разным причинам:

Моя система:

# 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

Я должен использовать как минимум ядро ​​3.9 или новее, поскольку я использую функции NAT IPv6, предоставляемые Linux 3.9 или новее (да, я знаю, что вам не следует использовать NAT с IPv6, но это другая история).

Спасибо за вашу помощь!

Редактировать:

Я провел несколько экспериментов, используя устройства dd и loop. Такое поведение вообще не характерно для LVM.

Тесты:

# 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

Поэтому всякий раз, когда вы пытаетесь смонтировать новое устройство с клонированной файловой системой btrfs внутри, вы в конечном итоге используете старое, уже смонтированное устройство (но ничто в выводе mount не указывает на это правильно, как вы можете видеть в эксперименте LVM выше). Таким образом, все запросы заканчиваются использованием старого устройства. Вы не сможете смонтировать клонированную файловую систему, пока не отключите исходную файловую систему (и вы не можете смонтировать исходную файловую систему, пока смонтирована клонированная).

Теперь мой вопрос: как я могу изменить uuid клонированных btrfs на новый неиспользуемый uuid. Я подозреваю, что после этого я смогу установить клонированное устройство вместе с оригинальным.

Похоже, такое поведение вызывает udev.

Выполнение lvcreate (или losetup) вызывает действия udev по «изменению» в «блочной» системе:

# 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)
...

который запускает (в моем случае) правила из

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

и вызывает встроенную команду udev:

IMPORT{builtin}="btrfs ready $devnode"

который проходит через src / udev / udev-builtin-btrfs.c: 52

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

Чтобы попасть в ядро ​​по адресу: http://lxr.free-electrons.com/source/fs/btrfs/volumes.c#L848 вызывая dmesg вроде:

...
[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
...

Непонятно, что именно вызывает «перемонтирование» и зачем оно нужно. Но замечания о том, что виноват повторяющийся UUID, не кажутся надуманными.

Я даже не уверен, что такое перемонтирование (изменение устройства существующей точки монтирования) желательно или полезно ...

Если вы хотите изменить поведение, вы можете изменить или удалить правила btrfs-udev с потерей функциональности: больше никаких автоматических подключений после горячего подключения USB-дисков btrfs.

Я не особо разбирался в этом, но btrfs как файловая система работает на группах дисков, а не на отдельных устройствах.

Я подозреваю, что btrfs не может отличить смонтированный снимок от реальной смонтированной файловой системы, когда происходит монтирование. Фактически он может видеть UUID нижележащего подобома, считать его зеркалом исходного тома и записывать данные на оба тома одновременно.

Я был бы удивлен, если бы это когда-нибудь исправили, поскольку для большинства целей и задач снимки btrfs заменяют снимки LVM.