Description of problem (please be detailed as possible and provide log snippests): Restoring a PVC in block volume mode from snapshot and re-writing the data with an attached pod, increases the thin-pool utility (Data%) without the LV utility. Before re-writing the data: LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert 06b91607-6ed9-4e33-a670-c5944f218139 vg1 Vwi-aotz-- 300.00g thin-pool-1 10.03 20630fc9-143b-4a94-96f5-be9c7ddebe8f vg1 Vri---tz-k 300.00g thin-pool-1 06b91607-6ed9-4e33-a670-c5944f218139 ac060e50-1c52-42be-af33-aab3d5c819d8 vg1 Vwi-aotz-k 300.00g thin-pool-1 20630fc9-143b-4a94-96f5-be9c7ddebe8f 10.03 thin-pool-1 vg1 twi-aotz-- <674.81g 4.46 11.63 After re-writing the data: LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert 06b91607-6ed9-4e33-a670-c5944f218139 vg1 Vwi-aotz-- 300.00g thin-pool-1 10.03 20630fc9-143b-4a94-96f5-be9c7ddebe8f vg1 Vri---tz-k 300.00g thin-pool-1 06b91607-6ed9-4e33-a670-c5944f218139 ac060e50-1c52-42be-af33-aab3d5c819d8 vg1 Vwi-aotz-k 300.00g thin-pool-1 20630fc9-143b-4a94-96f5-be9c7ddebe8f 10.03 thin-pool-1 vg1 twi-aotz-- <674.81g 8.91 12.84 No LV utility increased but the overall utility of the thin-pool increased. Version of all relevant components (if applicable): 4.11.0-113 Does this issue impact your ability to continue to work with the product (please explain in detail what is the user impact)? Total utility is wrong Is there any workaround available to the best of your knowledge? No Rate from 1 - 5 the complexity of the scenario you performed that caused this bug (1 - very simple, 5 - very complex)? 1 Can this issue reproducible? Yes Can this issue reproduce from the UI? If this is a regression, please provide more details to justify this: No Steps to Reproduce: 1. Install LVMO 2. Create a PVC in block mode and attach it to POD, run IO. 3. Create a snapshot from the PVC, restore it, attach a new POD and run the same IO 4. run "sudo lvs" on SNO node Actual results: The utility of the thin-pool increases but the LV doesn't. LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert 06b91607-6ed9-4e33-a670-c5944f218139 vg1 Vwi-aotz-- 300.00g thin-pool-1 10.03 20630fc9-143b-4a94-96f5-be9c7ddebe8f vg1 Vri---tz-k 300.00g thin-pool-1 06b91607-6ed9-4e33-a670-c5944f218139 ac060e50-1c52-42be-af33-aab3d5c819d8 vg1 Vwi-aotz-k 300.00g thin-pool-1 20630fc9-143b-4a94-96f5-be9c7ddebe8f 10.03 thin-pool-1 vg1 twi-aotz-- <674.81g 8.91 12.84 Expected results: The thin-pool utility shouldn't change as the restored PVC data is still the snapshot data as data hasn't been change. Additional info: lvs after first IO: LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert 06b91607-6ed9-4e33-a670-c5944f218139 vg1 Vwi-aotz-- 300.00g thin-pool-1 10.03 thin-pool-1 vg1 twi-aotz-- <674.81g 4.46 11.63 lvs after creating the snapshot LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert 06b91607-6ed9-4e33-a670-c5944f218139 vg1 Vwi-aotz-- 300.00g thin-pool-1 10.03 20630fc9-143b-4a94-96f5-be9c7ddebe8f vg1 Vri---tz-k 300.00g thin-pool-1 06b91607-6ed9-4e33-a670-c5944f218139 thin-pool-1 vg1 twi-aotz-- <674.81g 4.46 11.63 lvs after PVC restore LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert 06b91607-6ed9-4e33-a670-c5944f218139 vg1 Vwi-aotz-- 300.00g thin-pool-1 10.03 20630fc9-143b-4a94-96f5-be9c7ddebe8f vg1 Vri---tz-k 300.00g thin-pool-1 06b91607-6ed9-4e33-a670-c5944f218139 ac060e50-1c52-42be-af33-aab3d5c819d8 vg1 Vwi-aotz-k 300.00g thin-pool-1 20630fc9-143b-4a94-96f5-be9c7ddebe8f 10.03 thin-pool-1 vg1 twi-aotz-- <674.81g 4.46 11.63 lvs after re-writing same data to restored PVC LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert 06b91607-6ed9-4e33-a670-c5944f218139 vg1 Vwi-aotz-- 300.00g thin-pool-1 10.03 20630fc9-143b-4a94-96f5-be9c7ddebe8f vg1 Vri---tz-k 300.00g thin-pool-1 06b91607-6ed9-4e33-a670-c5944f218139 ac060e50-1c52-42be-af33-aab3d5c819d8 vg1 Vwi-aotz-k 300.00g thin-pool-1 20630fc9-143b-4a94-96f5-be9c7ddebe8f 10.03 thin-pool-1 vg1 twi-aotz-- <674.81g 8.91 12.84
Must gather is for these LV: LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert 5c59aae6-c0a0-4ca2-944e-da6532956f57 vg1 Vwi-aotz-k 300.00g thin-pool-1 d224d50e-8350-49e3-91bf-218bb4fd263b 10.03 d132ce18-9006-446c-a9eb-78d38260bbc1 vg1 Vwi-aotz-- 300.00g thin-pool-1 10.03 d224d50e-8350-49e3-91bf-218bb4fd263b vg1 Vri---tz-k 300.00g thin-pool-1 d132ce18-9006-446c-a9eb-78d38260bbc1 thin-pool-1 vg1 twi-aotz-- <674.81g 8.91 12.76
If this is the behavior that should be - As new restored data changed and it is counted in thin-pool utilization, the K attribute of the restored PVC should be removed aka move it from "activation skip" to activate.
I see that you activated the restore. This is what I think missing in LVMO, when the data of the restored PVC was written I think it should be activated. In my issue it stays in "skip activation" (k attribute): LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert 5c59aae6-c0a0-4ca2-944e-da6532956f57 vg1 Vwi-aotz-k 300.00g thin-pool-1 d224d50e-8350-49e3-91bf-218bb4fd263b 10.03 d132ce18-9006-446c-a9eb-78d38260bbc1 vg1 Vwi-aotz-- 300.00g thin-pool-1 10.03 d224d50e-8350-49e3-91bf-218bb4fd263b vg1 Vri---tz-k 300.00g thin-pool-1 d132ce18-9006-446c-a9eb-78d38260bbc1 thin-pool-1 vg1 twi-aotz-- <674.81g 8.91 12.76 How come a data from a none activated LV could be counted?