Why a frozen snapshot of a LV is changing continuously?

Question

Before I install gcc-8.3.0, I take a snapshot of the root("/") LV as following command:

lvcreate -L 20G -s vgsys/lvroot -n lvroot_gcc7

Then, I installed gcc-8.3.0, and taked another snapshot of the root LV as following:

lvcreate -L 25G -s vgsys/lvroot -n lvroot_gcc8

Now, my system looks like that:

root# lvs
LV          VG    Attr       LSize  Pool Origin Data%  Meta%  Move Log         Cpy%Sync Convert   
lvhome      vgsys -wi-ao---- 80.00g                
lvroot      vgsys owi-aos--- 64.00g                                   
lvroot_gcc7 vgsys swi-a-s--- 20.00g      lvroot 5.26  
lvroot_gcc8 vgsys swi-a-s--- 25.00g      lvroot 0.00

After I used this system for a while, I found that the Using-Percentage(Data%) of lvroot_gcc7 is changing continuously same as lvroot_gcc8!

Now, this is the status of my system:

LV          VG    Attr       LSize  Pool Origin Data%  Meta%  Move Log    Cpy%Sync Convert
lvhome      vgsys -wi-ao---- 80.00g                
lvroot      vgsys owi-aos--- 64.00g                                   
lvroot_gcc7 vgsys swi-a-s--- 20.00g      lvroot 6.05                  
lvroot_gcc8 vgsys swi-a-s--- 25.00g      lvroot 0.86

BTW, every time before I taking a snapshots, I would reboot the system with a Kubuntu 18.04.2 installation medium USB-stick, and take snapshots of lvroot always when it was not mounted.

Why the lvroot_gcc7 is still changing after the lvroot_gcc8 has been created?

As my comprehension, after I created the 1st snapshot of lvroot, before the 2nd one, if the data in lvroot is about to be over-written, it would be first read out and written to the 1st snapshot. But after I created the 2nd snapshot, the data about to be over-written should be read out and written to the 2nd snapshot ONLY, unless the 2nd snapshot is invalid or out of space, the old data would be copied to the 1st snapshot instead. This is the way how LVM systems trace the changes of LVs. Many snapshots of same original LV compose a link in this way. If my comprehension is right, the 1st snapshot had been frozen after the 2nd snapshot had been created, so that there should not be any writing operation occured to the 1st one if the 2nd one has enough free space for tracing the changes to lvroot, and the used size of the 1st one should NOT be changing continuously.

Answer 1

LVM snapshots are copy-on-write. That means that when you create one, you instantly have a snapshot, but it is kept constant by the copy-on-write algorithm: When lvroot gets written to, the data to be written is first read, and written to the snapshot. That way, you retain the original data. This obviously costs space, and this is why a snapshot needs to have enough space.

It's normal behavior. It also means reduced performance per snapshot.

I would also like to warn you about the possibility of actually mounting a snapshot instead of the original lvroot on boot. Often times, /etc/fstab has UUID's in them, to uniquely identify file systems. However, the file system UUID's of the snapshots are identical, so it may accidentally mount the wrong one.

You can mitigate that by adding --permission r when creating the snapshot. That way, you will know right away when you're using the wrong one, because you will get errors about it being read-only.

As for your addition to your question: I've never used the thinpools A.B describes, but traditional snapshots when taken from the root, operate independently of each other, can be merged or deleted separately.