Home / server / Questions / 1157873
Accepted
avi9526
Asked: 2024-04-14 02:22:49 +0800 CST

Thin provisioned LVM snapshot became separate volume without origin

  • 772

I was playing with my LVM thin installation. Created multiple snapshots, merged them with origin many times. At some point in the output of lvs -a command oldest snapshots lost its origin. In the output of more detailed command lvs -a -o time,name,origin,lv_role this snapshots are now have lv_role as public (while snapshots have roles public,snapshot,thinsnapshot). merge is now not possible with error is not a mergeable logical volume. Now I have multiple questions:

  1. is this orphaned snapshots are proper volumes or they are corrupted?
  2. why does this happen? (I was merging some middle in terms of creation time snapshots with their origin and then recreating them)
  3. can I manually remove origin from a snapshot to make it separated volume?
  4. is there a way back for this volumes to became snapshots with equal blocks of data being linked to origin again to preserve space?

Update. Test script.

initial config with name of VG and pool that should exist:

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

create test LV and make it random

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 output:

  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

now merge one snapshot:

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

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

output:

  test                                 public                                  
  test_snap_0                     public                                  
  test_snap_1                     public                                  
  test_snap_3                     public

this snapshots are now just volumes, they may share some blocks with each other, sha256sum shows that data are intact, overriding one does not affect others.

It's quite strange why they lose origin but still have common data blocks.

lvm

1 Answers

  1. Best Answer

    When two thinly provisioned volumes have shared data blocks, it doesn't imply that one must be an origin of another, or that both of them must have the same origin (at the moment; it is most likely they had the same origin in the past).

    To demonstrate this I'll create a setup like yours:

      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

    except that I made test and test_snap_1 to share the first 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  -

    and made test_snap_0 and test_snap_1 to share second 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  -

    The third 4 MiB region is shared by all three.

    Now, merging 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

    The test_snap_1 was based on former test, which was removed and replaced with other volume, so now test_snap_1 has nothing to be based on. But its data is still as it should:

    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  -

    To verify that these blocks are still shared, we'll dump thin pool metadata:

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

    Here dev_id="4" is test, and dev_id="5" is test_snap_1 (can be identified using /etc/lvm/backup/vg). The dev 4 maps where the former origin was residing, to the "physical" chunks (stored in pool0_tdata) from 0 to 192. Whereas, the first 64 chunks of dev 5 map to some space past this stretch. But 128 chunks of dev 5 starting from 64 actually point to the same place as they do in dev 4, e.g. these chunks are shared. Notice that these are "thin lvm" chunks, of 64KiB size each (which is default, can be set when creating the thin pool and queried using lvs -o name,chunksize); 128 * 64KiB gives 8MiB — that was the size of the region which is actually shared (remembering, third 4MiB was the same on all three volumes).

    If I rewrite the second 4MiB region of one volume, regions will be unshared and the data on the other volume won't be touched, correctly implementing the CoW semantic. But if I later make them same again, they won't magically merge back into a shared region. In principle, it should be possible to create a deduplication tool for thin LVM, which will merge same blocks into shared, saving some space, even without the new VDO technology, but I know of no such tool.

    References:

    • 0