btrfs 卷的 LVM 快照更改掛載的設備
我在 LVM 之上有一個 btrf 卷。現在我想在 lvm 級別上做一個快照（不是在 btrfs 級別上）。但是每次我創建 LVM 快照時，btrfs 都會將掛載的塊設備更改為快照，就像我使用某種 –bind 掛載選項一樣。
情況：
# 掛載 | grep libvirt /dev/dm-4 on/var/lib/libvirt/images 類型 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 已創建邏輯卷“vm_backup” # 掛載 | 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 # 掛載 /dev/system/vm_backup /mnt/test # 觸摸 /mnt/test/touchME # ls -l /var/lib/libvirt/images/touchME -rw-r - r-- 1 root root 0 Mar 17 01:26 / var / lib / libvirt / images / touchME當我刪除快照時：
# 解除安裝 /mnt/test # lvremove /dev/system/vm_backup 您真的要刪除活動邏輯卷 vm_backup 嗎？[是/否]：是 邏輯卷“vm_backup”已成功刪除 # 掛載 | grep libvirt /dev/dm-4 on/var/lib/libvirt/images 類型 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 Mar 17 01:26 / var / lib / libvirt / images / touchME我希望我的快照是真正的快照，而不是像 –bind 掛載那樣的東西。我正在使用 LVM 快照通過 rsync 將一致的系統狀態備份到我們的備份伺服器。而且出於各種原因，我不想使用 btrfs 快照：
- 我想備份 vm_disks LV 中的每個子捲和每個 btrfs 快照（而且我不知道存在多少以及哪些快照/子卷）
- 我的備份策略不應該依賴於文件系統。理想情況下，在 /var/lib/libvirt/images 更改文件系統時不需要更改任何其他內容
我的系統：
# unname -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 或更高版本，因為我使用 Linux 3.9 或更高版本提供的 IPv6 NAT 功能（是的，我知道您不應該將 NAT 與 IPv6 一起使用，但那是另一回事了）。
謝謝你的幫助！
編輯：
我使用 dd 和 loop 設備做了一些實驗。這種行為根本不是 LVM 特有的。
測試：
# mkfs.btrfs /dev/loop0 [...] # 掛載 /dev/loop0 原始 # touch original/original_file # ls -l 原版 -rw-r--r-- 1 根根 0 Mar 28 21:42 original_file # dd if=/dev/loop0 of=/dev/loop1 509312+0 條記錄 509312+0 條記錄輸出 複製了 260767744 字節 (261 MB)，1.76431 秒，148 MB/秒 # 掛載 /dev/loop1 複製 # 觸摸複製/expected_clone_file # ls -l 複製 -rw-r--r-- 1 根根 0 Mar 28 21:44 expected_clone_file -rw-r--r-- 1 根根 0 Mar 28 21:42 original_file # ls -l 原版 -rw-r--r-- 1 根根 0 Mar 28 21:44 expected_clone_file -rw-r--r-- 1 根根 0 Mar 28 21:42 original_file # 解除安裝複製 # 解除安裝原始文件 # 掛載 /dev/loop1 複製 # ls -l 複製 -rw-r--r-- 1 根根 0 Mar 28 21:42 original_file # 解除安裝複製 # 掛載 /dev/loop0 原始 # ls -l 原版 -rw-r--r-- 1 根根 0 Mar 28 21:44 expected_clone_file -rw-r--r-- 1 根根 0 Mar 28 21:42 original_file因此，每當您嘗試在內部使用複製的 btrfs 文件系統掛載新設備時，最終都會使用已掛載的舊設備（但 mount 的輸出中沒有任何內容正確表明這一點，正如您在上面的 LVM 實驗中看到的那樣）。因此，所有請求最終都使用舊設備。在解除安裝原始 fs 之前，您無法安裝複製的 fs（並且在安裝複製的 fs 時無法安裝原始 fs）。
我現在的問題是：如何將複製的 btrfs 的 uuid 更改為一些新的未使用的 uuid。我懷疑，在那之後，我將能夠將複製的設備與原始設備一起安裝。
我沒有對此進行大量研究，但是 btrfs 作為文件系統在磁碟組上工作，而不是在單個設備上工作。
我懷疑當掛載發生時，btrfs 無法區分掛載的快照和實際掛載的文件系統。事實上，它可能會看到底層子卷的 UUID，假設它是原始卷的鏡像並同時寫入兩個卷。
如果這個問題得到修復，我會感到驚訝，因為大多數意圖和目的 btrfs 快照取代了 LVM 快照。