Skip to content

Commit 948d19d

Browse files
committed
docs: Update FAQs
Signed-off-by: Bala Harish <bala.harish.ac@datacore.com>
1 parent 1c03264 commit 948d19d

File tree

1 file changed

+35
-1
lines changed
  • docs/versioned_docs/version-4.3.x/faqs

1 file changed

+35
-1
lines changed

docs/versioned_docs/version-4.3.x/faqs/faqs.md

Lines changed: 35 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -580,7 +580,41 @@ The supportability tool generates support bundles, which are used for debugging
580580
581581
### What happens when a PV with reclaim policy set to retain is deleted?
582582
583-
In Kubernetes, when a PVC is created with the reclaim policy set to 'Retain', the PV bound to this PVC is not deleted even if the PVC is deleted. One can manually delete the PV by issuing the command "kubectl delete pv", however the underlying storage resources could be left behind as the CSI volume provisioner (external provisioner) is not aware of this. To resolve this issue of dangling storage objects, Replicated Storage has introduced a PV garbage collector. This PV garbage collector is deployed as a part of the Replicated Storage CSI controller-plugin.
583+
In Kubernetes, when a PVC that is bound to a PV with the reclaim policy set to Retain is deleted, the corresponding PV is not automatically removed. You can delete the PV manually by running the following command:
584+
585+
```
586+
kubectl delete pv <pv-name>
587+
```
588+
589+
However, deleting the PV manually may leave the underlying storage resources orphaned because the CSI external provisioner is not notified of the PV deletion.
590+
591+
Earlier, Replicated Storage automatically handled such orphaned storage objects through a PV Garbage Collector (GC) that was deployed as part of the Replicated Storage CSI controller plugin.
592+
593+
Starting with the latest update, the orphaned PV Garbage Collector is disabled by default. Instead, Replicated Storage provides a mechanism to manually identify and delete unbound volumes using the `kubectl-openebs` plugin. This approach allows administrators to control when and how orphaned volumes are removed, ensuring safer and more predictable cleanup of unused storage resources.
594+
595+
#### Identifying Orphaned Volumes
596+
597+
You can use a shell command to compare existing PVs with volumes reported by Mayastor and detect potential orphaned volumes:
598+
599+
```
600+
kubectl openebs -n openebs mayastor get volumes -o json | \
601+
jq -r --argjson pvs "$(kubectl get pv -o json)" \
602+
'.[] | select(.spec.uuid as $uuid | all($pvs.items[]; .metadata.name != ("pvc-" + $uuid))) | "Volume \(.spec.uuid) may be orphan"'
603+
```
604+
605+
**Sample Output**
606+
607+
```
608+
Volume 4bfe4c23-b32b-4e59-ac39-148646e4f844 may be orphan
609+
```
610+
611+
#### Deleting a Specific Volume
612+
613+
Once an orphaned volume is identified, it can be deleted by its UUID using:
614+
615+
```
616+
kubectl openebs -n openebs mayastor volume delete <volume-uuid>
617+
```
584618
585619
[Go to top](#top)
586620

0 commit comments

Comments
 (0)