From 6ac37b76be9401bc5a6dcd882a40770224c6935c Mon Sep 17 00:00:00 2001 From: Omar Saleem Date: Sat, 15 Aug 2020 13:07:42 -0400 Subject: [PATCH] fix a typo you "lose" data not "loose" data. quick fix --- content/en/docs/concepts/storage/persistent-volumes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/concepts/storage/persistent-volumes.md b/content/en/docs/concepts/storage/persistent-volumes.md index 4933513929..8c2ad3ddb1 100644 --- a/content/en/docs/concepts/storage/persistent-volumes.md +++ b/content/en/docs/concepts/storage/persistent-volumes.md @@ -259,7 +259,7 @@ Expanding EBS volumes is a time-consuming operation. Also, there is a per-volume If expanding underlying storage fails, the cluster administrator can manually recover the Persistent Volume Claim (PVC) state and cancel the resize requests. Otherwise, the resize requests are continuously retried by the controller without administrator intervention. 1. Mark the PersistentVolume(PV) that is bound to the PersistentVolumeClaim(PVC) with `Retain` reclaim policy. -2. Delete the PVC. Since PV has `Retain` reclaim policy - we will not loose any data when we recreate the PVC. +2. Delete the PVC. Since PV has `Retain` reclaim policy - we will not lose any data when we recreate the PVC. 3. Delete the `claimRef` entry from PV specs, so as new PVC can bind to it. This should make the PV `Available`. 4. Re-create the PVC with smaller size than PV and set `volumeName` field of the PVC to the name of the PV. This should bind new PVC to existing PV. 5. Don't forget to restore the reclaim policy of the PV.