Bug 2107948 - Restored PVC still in "skip activation" after snapshot and origin PVC deleted.
Summary: Restored PVC still in "skip activation" after snapshot and origin PVC deleted.
Keywords:
Status: VERIFIED
Alias: None
Product: Red Hat OpenShift Data Foundation
Classification: Red Hat Storage
Component: lvm-operator
Version: 4.11
Hardware: Unspecified
OS: Unspecified
unspecified
urgent
Target Milestone: ---
: ODF 4.11.0
Assignee: N Balachandran
QA Contact: Shay Rozen
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-07-17 23:20 UTC by Shay Rozen
Modified: 2023-08-09 16:46 UTC (History)
5 users (show)

Fixed In Version: 4.11.0-113
Doc Type: No Doc Update
Doc Text:
Clone Of:
Environment:
Last Closed:
Embargoed:


Attachments (Terms of Use)
must gather (270.62 KB, application/gzip)
2022-07-17 23:20 UTC, Shay Rozen
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Github red-hat-storage topolvm pull 15 0 None open Bug 2107948: disable activation skip 2022-07-19 12:56:41 UTC
Github topolvm topolvm pull 534 0 None open lvm: disable activation skip 2022-07-19 09:00:28 UTC

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


Note You need to log in before you can comment on or make changes to this bug.