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