Bug 2107948

Summary: Restored PVC still in "skip activation" after snapshot and origin PVC deleted.
Product: [Red Hat Storage] Red Hat OpenShift Data Foundation Reporter: Shay Rozen <srozen>
Component: lvm-operatorAssignee: N Balachandran <nibalach>
Status: VERIFIED --- QA Contact: Shay Rozen <srozen>
Severity: urgent Docs Contact:
Priority: unspecified    
Version: 4.11CC: jolmomar, lgangava, muagarwa, odf-bz-bot, sapillai
Target Milestone: ---   
Target Release: ODF 4.11.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: 4.11.0-113 Doc Type: No Doc Update
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
must gather none

Description Shay Rozen 2022-07-17 23:20:29 UTC
Created attachment 1897854 [details]
must gather

Description of problem (please be detailed as possible and provide log
snippests):
When deleting snapshot and origin PVC, the restored PVC not activate (remove the k attribue), and there for you can create lots of restores that don't count in thin-pool utilization although their origin has bin deleted.
  LV                                   VG  Attr       LSize    Pool        Origin Data%  Meta%  Move Log Cpy%Sync Convert
  55495db4-a0fb-4ef9-aedf-155d3e6546fa vg1 Vwi-aotz-k  300.00g thin-pool-1        10.05                                  
  thin-pool-1                          vg1 twi-aotz-- <674.81g                    4.47   11.99                           

The restored PVC is the only one left but still in "skip activation" by the k in Vwi-aotz-k 

I can make as much restores PVC and delete their origin snapshot and PVC and still utilization of thin pool will not rise:
  LV                                   VG  Attr       LSize    Pool        Origin Data%  Meta%  Move Log Cpy%Sync Convert
  49eb51fd-64ec-445b-8146-1aaa7f6b6c70 vg1 Vwi-aotz-k  300.00g thin-pool-1        10.05
  672dc900-2968-4878-9b83-4c26841efaa6 vg1 Vwi-aotz-k  300.00g thin-pool-1        10.05
  6a8cf9ba-0aa4-4163-a27c-985da5ad0ae8 vg1 Vwi-aotz-k  300.00g thin-pool-1        10.05
  99dae9c8-8e4d-44b6-ab84-57e9d4b41044 vg1 Vwi-aotz-k  300.00g thin-pool-1        10.05
  d54cea58-e74c-4812-a7fb-67178ccd1132 vg1 Vwi-aotz-k  300.00g thin-pool-1        10.05
  thin-pool-1                          vg1 twi-aotz-- <674.81g                    4.47   12.12

Also thin-pool util doesn't change when deleting the origin PVC

Version of all relevant components (if applicable):
4.11.0-113 and checked also older one.

Does this issue impact your ability to continue to work with the product
(please explain in detail what is the user impact)?
Restores are not activated and their utilization not shown.

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?
Yes

If this is a regression, please provide more details to justify this:
No

Steps to Reproduce:
1. Install lvmcluster
2. Create a PVC and attach a pod, run IO
3. Create snapshot from the a bove PVC.
4. restore it.
5. Attach a pod to the PVC (to get to bounding mode)
6. Step 4-5 can be repeated to have more PVC with not origin.
7. Delete snapshot, Delete origin PVC. 
8. Check lvs command
repro bash script available at: https://github.com/shyRozen/Toolz/blob/main/repro/snapshot_fs_delete.sh

Actual results:
Many PVC restore that their origin gone and their utilization doesn't count.

Expected results:
The restored PVC should be activated once their snapshot or origin PVC deleted


Additional info:
thinpool-size doesn't change which should be more than half of utilization.

  LV                                   VG  Attr       LSize    Pool        Origin Data%  Meta%  Move Log Cpy%Sync Convert
  174139da-edc0-4d93-b8a7-f811ec39bfc6 vg1 Vwi-aotz-k  300.00g thin-pool-1        10.05
  1fd6997a-10bb-4245-849e-6ebe01dd16fd vg1 Vwi-aotz-k  300.00g thin-pool-1        10.05
  257328ec-1231-4a31-9db6-b55357757292 vg1 Vwi-aotz-k  300.00g thin-pool-1        10.05
  3d160f68-cbe4-459b-90f8-ae89b0d9365c vg1 Vwi-aotz-k  300.00g thin-pool-1        10.05
  3f58d8b0-7d0b-4f17-9538-41b8cc6e26d4 vg1 Vwi-aotz-k  300.00g thin-pool-1        10.05
  4c4d1a28-74dc-47c1-964d-833253361969 vg1 Vwi-aotz-k  300.00g thin-pool-1        10.05
  605b4c82-2e82-4aa2-a32c-e399b81d7e2a vg1 Vwi-aotz-k  300.00g thin-pool-1        10.05
  b864fd3a-3fa2-41f8-a90f-b3a897ce4970 vg1 Vwi-aotz-k  300.00g thin-pool-1        10.05
  bc59d617-a15d-4ed6-9479-bf27ad2f9c1e vg1 Vwi-aotz-k  300.00g thin-pool-1        10.05
  bf987a7a-36a7-43f8-bdb8-49efc61ce2c1 vg1 Vwi-aotz-k  300.00g thin-pool-1        10.05
  db3f1f94-0a0f-49b8-baa4-55ef44639eae vg1 Vwi-aotz-k  300.00g thin-pool-1        10.05
  e2503638-c2e4-49fa-98f3-d1fe2622d2cc vg1 Vwi-aotz-k  300.00g thin-pool-1        10.05
  f2a25e58-b0bd-43aa-ac0b-3839608f3eaa vg1 Vwi-aotz-k  300.00g thin-pool-1        10.05
  fc2c5d07-51d7-4e0a-84f0-a2369e9b1269 vg1 Vwi-aotz-k  300.00g thin-pool-1        10.05
  thin-pool-1                          vg1 twi-aotz-- <674.81g                    4.47   12.31

Comment 6 Shay Rozen 2022-07-18 10:31:56 UTC
Hi Yug. Thanks you for elaborating. Still one question wasn't answer is if the blocks of the origin PVC are protected somehow from being re-written?

Comment 8 Yug Gupta 2022-07-19 08:59:58 UTC
Here is a PR with the fix: https://github.com/topolvm/topolvm/pull/534

Comment 11 Shay Rozen 2022-07-26 13:52:51 UTC
  f5e27c6d-d3af-4f20-8474-52973a9d7b7c vg1 Vwi-aotz--  100.00g thin-pool-1        1.06
 restore doesn't have k attribute