主页 / server / 问题 / 1157873
Accepted
avi9526
Asked: 2024-04-14 02:22:49 +0800 CST

精简配置的 LVM 快照成为没有来源的单独卷

  • 772

我正在玩我的 LVM 精简安装。创建多个快照，并将它们多次与原点合并。在命令输出中的某个时刻，lvs -a最旧的快照丢失了其起源。在更详细命令的输出中，lvs -a -o time,name,origin,lv_role此快照现在具有lv_role（public而快照具有 Roles public,snapshot,thinsnapshot）。merge现在不可能出现错误is not a mergeable logical volume。现在我有多个问题：

  1. 这个孤立的快照是正确的卷还是已损坏？
  2. 为什么会发生这种情况？（我将创建时间快照的一些中间部分与其起源合并，然后重新创建它们）
  3. 我可以手动从快照中删除源以使其成为单独的卷吗？
  4. 有没有办法让这些卷成为快照，并将相同的数据块再次链接到原点以保留空间？

更新。测试脚本。

带有 VG 名称和应该存在的池的初始配置：

VG=vg
Pool="${VG}"/pool0
Test_volume="test"

创建测试 LV 并使其随机

lvcreate -V10M -T "${Pool}" -n "${Test_volume}"

lvchange -ay -Ky "${VG}"/"${Test_volume}"

dd if=/dev/urandom of="/dev/${VG}/${Test_volume}"
lvcreate -n "${Test_volume}_snap_0" --snapshot "${VG}"/"${Test_volume}"
lvchange -ay -Ky "${VG}"/"${Test_volume}_snap_0"

dd if=/dev/urandom of="/dev/${VG}/${Test_volume}"
lvcreate -n "${Test_volume}_snap_1" --snapshot "${VG}"/"${Test_volume}"
lvchange -ay -Ky "${VG}"/"${Test_volume}_snap_1"

dd if=/dev/urandom of="/dev/${VG}/${Test_volume}"
lvcreate -n "${Test_volume}_snap_2" --snapshot "${VG}"/"${Test_volume}"
lvchange -ay -Ky "${VG}"/"${Test_volume}_snap_2"

dd if=/dev/urandom of="/dev/${VG}/${Test_volume}"
lvcreate -n "${Test_volume}_snap_3" --snapshot "${VG}"/"${Test_volume}"
lvchange -ay -Ky "${VG}"/"${Test_volume}_snap_3"

sha256sum "/dev/${VG}/${Test_volume}_snap"*

lvs -a -o name,origin,lv_role| grep "${Test_volume}"

lvs输出：

  test                                   public,origin,thinorigin,multithinorigin
  test_snap_0              test   public,snapshot,thinsnapshot            
  test_snap_1              test   public,snapshot,thinsnapshot            
  test_snap_2              test   public,snapshot,thinsnapshot            
  test_snap_3              test   public,snapshot,thinsnapshot

现在合并一个快照：

lvconvert --merge "${VG}/${Test_volume}_snap_2"

lvs -a -o name,origin,lv_role| grep "${Test_volume}"

输出：

  test                                 public                                  
  test_snap_0                     public                                  
  test_snap_1                     public                                  
  test_snap_3                     public

该快照现在只是卷，它们可能彼此共享一些块，sha256sum表明数据完好无损，覆盖其中一个不会影响其他快照。

很奇怪为什么它们失去了起源但仍然有共同的数据块。

lvm

1 个回答

  1. Best Answer

    当两个精简配置卷具有共享数据块时，并不意味着一个卷必须是另一个卷的来源，或者它们都必须具有相同的来源（目前；很可能它们在过去的）。

    为了演示这一点，我将创建一个像您一样的设置：

      LV          Origin Role                                    
  test               public,origin,thinorigin,multithinorigin
  test_snap_0 test   public,snapshot,thinsnapshot            
  test_snap_1 test   public,snapshot,thinsnapshot            

95e39bac4333499ebb1cacd8c6aed894c6dddcc2d36505791f9edc81527604be  /dev/vg/test
13b4464ba0c3d5c56bcaaa0b600a1118cb391e390457f5d29db6228e403bac9a  /dev/vg/test_snap_0
40354ff7b2ac521485bf3ff5dd012cd4919221e5fc4e32369281c784f4b9304c  /dev/vg/test_snap_1

    除了我做了 test 和 test_snap_1 来共享前 4M：

    # dd if=/dev/vg/test bs=4M count=1 2>/dev/null| sha256sum -
c1f080af2d79f17866522cc5105e248d0ab54d6032a4ff6c384b243d1c1f9837  -

# dd if=/dev/vg/test_snap_0 bs=4M count=1 2>/dev/null | sha256sum -
f4d6a9846b45cfab26a20b3cf56317bf4588f837d423002022f92ca605784622  -

# dd if=/dev/vg/test_snap_1 bs=4M count=1 2>/dev/null | sha256sum -
c1f080af2d79f17866522cc5105e248d0ab54d6032a4ff6c384b243d1c1f9837  -

    并使 test_snap_0 和 test_snap_1 共享第二个 4M：

    root@test-lvm:~# dd if=/dev/vg/test bs=4M count=1 skip=1 2>/dev/null | sha256sum -
9bf134a0e8727ed6d7087c529f3ce5136a1b10cd31286b5ffda10d0d6708b876  -

root@test-lvm:~# dd if=/dev/vg/test_snap_0 bs=4M count=1 skip=1 2>/dev/null | sha256sum -
01b7a2edcc06a1181db0e77d94c2379df658e240a61f6d1d5e5bce087448212d  -

root@test-lvm:~# dd if=/dev/vg/test_snap_1 bs=4M count=1 skip=1 2>/dev/null | sha256sum -
01b7a2edcc06a1181db0e77d94c2379df658e240a61f6d1d5e5bce087448212d  -

    第三个 4 MiB 区域由所有三个区域共享。

    现在，合并test_snap_0：

    root@test-lvm:~# lvconvert --merge /dev/vg/test_snap_0
  Volume vg/test_snap_0 replaced origin vg/test.

root@test-lvm:~# lvs -o name,origin,lv_role
  LV          Origin Role      
  pool0              private   
  test               public    
  test_snap_1        public

    该书test_snap_1是基于前者的test，后者已被删除并被其他卷取代，因此现在test_snap_1没有任何依据。但它的数据仍然是应该的：

    root@test-lvm:~# dd if=/dev/vg/test bs=4M count=1 skip=1 2>/dev/null | sha256sum -
01b7a2edcc06a1181db0e77d94c2379df658e240a61f6d1d5e5bce087448212d  -

root@test-lvm:~# dd if=/dev/vg/test_snap_1 bs=4M count=1 skip=1  2>/dev/null | sha256sum -
01b7a2edcc06a1181db0e77d94c2379df658e240a61f6d1d5e5bce087448212d  -

    为了验证这些块是否仍然共享，我们将转储精简池元数据：

    # dmsetup message /dev/mapper/vg-pool0-tpool 0 reserve_metadata_snap
# thin_dump --format xml -m  /dev/mapper/vg-pool0_tmeta > /tmp/dump.xml
# dmsetup message /dev/mapper/vg-pool0-tpool 0 release_metadata_snap

    <superblock uuid="" time="5" transaction="10" flags="0" version="2" data_block_size="128" nr_data_blocks="0">
  <device dev_id="4" mapped_blocks="192" transaction="7" creation_time="4" snap_time="4">
    <range_mapping origin_begin="0" data_begin="0" length="192" time="0"/>
  </device>
  <device dev_id="5" mapped_blocks="192" transaction="8" creation_time="5" snap_time="5">
    <range_mapping origin_begin="0" data_begin="768" length="64" time="4"/>
    <range_mapping origin_begin="64" data_begin="64" length="128" time="0"/>
  </device>
</superblock>

    这里dev_id="4"是test、 和dev_id="5"是test_snap_1（可以使用 来识别/etc/lvm/backup/vg）。dev 4 将先前原点所在的位置映射到pool0_tdata从 0 到 192 的“物理”块（存储在 中）。而 dev 5 的前 64 个块映射到超出此范围的某个空间。但 dev 5 中从 64 开始的 128 个块实际上与 dev 4 中的指向相同的位置，例如，这些块是共享的。请注意，这些是“thin lvm”块，每个大小为 64KiB（默认值，可以在创建精简池时设置并使用 查询lvs -o name,chunksize）；128 * 64KiB 给出 8MiB — 这是实际共享的区域的大小（记住，第三个 4MiB 在所有三个卷上都是相同的）。

    如果我重写一个卷的第二个 4MiB 区域，区域将不再共享，并且另一个卷上的数据不会被触及，从而正确实现 CoW 语义。但如果我稍后再次使它们相同，它们将不会神奇地合并回共享区域。原则上，应该可以为精简LVM创建一个重复数据删除工具，它将相同的块合并为共享块，节省一些空间，即使没有新的VDO技术，但我知道没有这样的工具。

    参考：

    • 0

相关问题