Снимок LVM тома btrfs изменяет подключенное устройство
У меня объем btrf поверх LVM. Теперь я хочу сделать снимок на уровне lvm (НЕ на уровне btrfs). Но каждый раз, когда я создаю снимок LVM, btrfs изменяет подключенное блочное устройство на снимок, как я использовал какую-то опцию --bind mount.
Ситуация:
# mount | grep libvirt /dev/dm-4 для / var / lib / libvirt / images типа btrfs (rw,relaytime,space_cache) # ls -l /dev/mapper | grep dm-4 lrwxrwxrwx 1 корневой корень 7 марта 17 01:18 system-vm_disks -> ../dm-4 # lvcreate -s /dev/system/vm_disks -n vm_backup -L 32G Логический том "vm_backup" создан # mount | grep libvirt /dev/dm-5 для / var / lib / libvirt / images типа btrfs (rw,relatime,space_cache) # ls -l /dev/mapper | grep dm-5 lrwxrwxrwx 1 корневой корень 7 марта 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 мар 17 01:26 /var/lib/libvirt/images/touchME
Когда я удаляю снимок:
# umount / mnt / test # lvremove / dev / system / vm_backup Вы действительно хотите удалить активный логический том vm_backup? [y/n]: y Логический том "vm_backup" успешно удален # mount | grep libvirt /dev/dm-4 для / var / lib / libvirt / images типа btrfs (rw,relaytime,space_cache) # ls -l /dev/mapper | grep dm-4 lrwxrwxrwx 1 корневой корень 7 марта 17 01:21 system-vm_disks -> ../dm-4 # ls -l /var/lib/libvirt/images/touchME -rw-r-r-- 1 root root 0 мар 17 01:26 /var/lib/libvirt/images/touchME
Я ожидаю, что мой снимок будет настоящим снимком, а не чем-то вроде --bind mount. Я использую снимки LVM для резервного копирования согласованного состояния системы через rsync на наш сервер резервного копирования. И я не хочу использовать снимки btrfs по разным причинам:
- Я хочу сделать резервную копию каждого подобъема и каждого снимка btrfs в LV vm_disks (и я не знаю, сколько и какие существуют снимки / подобъемы)
- Моя стратегия резервного копирования не должна зависеть от файловой системы. В идеале не должно быть необходимости что-либо менять при изменении файловой системы в / var / lib / libvirt / images
Моя система:
# uname -a ноутбук Linux 3.12-1-amd64 #1 SMP Debian 3.12.9-1 (2014-02-01) x86_64 GNU/Linux # lvm версия LVM версия: 2.02.104(2) (2013-11-13) Версия библиотеки: 1.02.83 (2013-11-13) Версия драйвера: 4.26.0 # btrfs --version Btrfs v3.12
Я должен использовать как минимум ядро 3.9 или новее, так как я использую возможности IPv6 NAT, предоставляемые Linux 3.9 или новее (да, я знаю, что вам не следует использовать NAT с IPv6, но это другая история).
Спасибо за вашу помощь!
Редактировать:
Я провел несколько экспериментов с использованием устройств dd и loop. Это поведение не является специфичным для LVM вообще.
тесты:
# mkfs.btrfs / dev / loop0 [...] # mount / dev / loop0 original # коснитесь оригинал / оригинал_файла # ls -l оригинал -rw-r -r-- 1 root root 0 мар 28 21:42 original_file # dd if=/dev/loop0 of=/dev/loop1 509312+0 записей в 509312 + 0 записей Скопировано 260767744 байта (261 МБ), 1,76431 с, 148 МБ / с # mount /dev/loop1 clone # touch clone/ Ожидаемый_clone_file # ls -l clone -rw-r- r-- 1 корневой root 0 марта 28 21:44 Ожидаемый_clone_file -rw-r-r-- 1 root root 0 мар 28 21:42 original_file # ls -l оригинал -rw-r - r-- 1 корневой root 0 марта 28 21:44 Ожидаемый_clone_file -rw-r-r-- 1 root root 0 мар 28 21:42 original_file # размонтировать клон # оригинал # mount /dev/loop1 clone # ls -l clone -rw-r-r-- 1 root root 0 мар 28 21:42 original_file # размонтировать клон # mount /dev/loop0 original # ls -l оригинал -rw-r - r-- 1 корневой root 0 марта 28 21:44 Ожидаемый_clone_file -rw-r-r-- 1 root root 0 мар 28 21:42 original_file
Поэтому всякий раз, когда вы пытаетесь смонтировать новое устройство с клонированной файловой системой btrfs внутри, вы в конечном итоге используете старое уже смонтированное устройство (но ничего в выводе mount не указывает на это должным образом, как вы можете видеть в эксперименте LVM выше). Таким образом, все запросы заканчиваются использованием старого устройства. Вы не сможете смонтировать клонированную fs, пока не размонтируете исходную fs (и вы не можете смонтировать исходную fs, пока монтируется клонированная).
Теперь у меня вопрос: как я могу изменить uuid клонированных btrfs на какой-то новый неиспользованный uuid. Я подозреваю, что после этого я смогу смонтировать клонированное устройство рядом с оригинальным.
2 ответа
Я не очень подробно разбирался в этом, но btrfs как файловая система работает на группах дисков, а не на отдельных устройствах.
Я подозреваю, что btrfs не может отличить смонтированный моментальный снимок от реальной смонтированной файловой системы при монтировании. Фактически он может увидеть UUID базового подобъема, предположить, что он является зеркалом исходного тома, и выполнить запись в оба тома одновременно.
Я был бы удивлен, если это когда-либо будет исправлено, поскольку большинство снимков и целей btrfs заменяют снимки LVM.
Кажется, что Udev вызывает это поведение.
Выполнение lvcreate (или losttup) вызывает действия udev "change" в системе "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)
...
который запускает (в моем случае) правила из
/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.