Overview
This guide introduces how to expand the capacity of a PersistentVolume (PV).
AWS
Method to expand the capacity of AWS
How to expand via AWS Console
1. Access the AWS Console (https://aws.amazon.com/console/), select “EC2” under Services → Select “Volumes” under Elastic Block Store → Search by volumeHandle (or PV name) and check the Size.
2. Click the “Actions” button at the top and select “Modify Volume”.
3. Change to the desired Size and click the “Modify” button.
4. When the confirmation window appears, click “Yes”.
<Note> If the volume was recently modified, it can be changed again after 6 hours.
5. Confirm the message indicating the modification is complete.
6. Check the modified capacity.
Expanding the file system after increasing capacity
1. Access the instance where the pod connected to the PV is running.
2. Check the PVC capacity
# It will show the previous capacity (1GB) $ df -hT | grep pvc-7e095b59-b814-4737-b672-f6b014d6e335 /dev/nvme1n1 ext4 976M 198M 763M 21% /var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-7e095b59-b814-4737-b672-f6b014d6e335/globalmount |
3. Check the block device with the changed capacity
# Changed $ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT nvme0n1 259:0 0 100G 0 disk ├─nvme0n1p1 259:1 0 100G 0 part / └─nvme0n1p128 259:2 0 1M 0 part nvme1n1 259:3 0 2G 0 disk /var/lib/kubelet/pods/73c7b7c0-0cb4-4737-841c-4b0b01cb767e/volumes/kubernetes.io~csi/pvc-7e095b59-b814-4737-b672-f6b014d6e335/mount
4. Expand the file system to apply the changed capacity
# /dev/xvda1: file system name sudo resize2fs /dev/xvda1 # 실행 예 $ sudo resize2fs /dev/nvme1n1 resize2fs 1.42.9 (28-Dec-2013) Filesystem at /dev/nvme1n1 is mounted on /var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-7e095b59-b814-4737-b672-f6b014d6e335/globalmount; on-line resizing required old_desc_blocks = 1, new_desc_blocks = 1 The filesystem on /dev/nvme1n1 is now 524288 blocks long.
5. Verify if it was applied correctly
$ df -hT | grep pvc-7e095b59-b814-4737-b672-f6b014d6e335 /dev/nvme1n1 ext4 2.0G 199M 1.8G 11% /var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-7e095b59-b814-4737-b672-f6b014d6e335/globalmount
Also enter the connected pod and verify
df -h /consul/data Filesystem Size Used Available Use% Mounted on /dev/nvme1n1 1.9G 198.1M 1.7G 10% /consul/data
Reference page
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/recognize-expanded-volume-linux.html
Modifying the defined capacity in PV and PVC to show the expanded size
This step is required to reflect the expanded capacity when checking with kubectl get pv or kubectl get pvc.
You can skip this step if you don’t mind seeing the old capacity.
[When the Reclaim Policy of the PV is “Retain” ]
1. PVC Backup
Back up the PVC of the PV.
$ kubectl get pvc <PVC name> -o yaml > <desired filename>.yaml |
2. Edit PVC yaml file <If the IOPS for Endurance was also changed, change the storage-class as well >
Modify the following 3 parts to the expanded capacity and save:
metadata > annotation > kubectl.kubernetes.io/last-applied-configuration
spec > resources > requests > storage
status > capacity > storage
$ vi <saved PVC filename>.yaml ... kubectl.kubernetes.io/last-applied-configuration: | {"apiVersion":"v1","kind":"PersistentVolumeClaim","metadata":{"annotations":{"kubernetes.io/change-cause":"kubectl apply --filename=k8s/prod/pvc.yaml --namespace=zcp-system --record=true","volume.beta.kubernetes.io/storage-class":"ibmc-block-retain-bronze"},"labels":{"billingType":"monthly"},"name":"pvc-test","namespace":"zcp-system"},"spec":{"accessModes":["ReadWriteOnce"],"resources":{"requests":{"storage":"30Gi"}}}} ... spec: ... resources: requests: storage: 20Gi ... status: ... capacity: storage: 30Gi ... |
3. PVC Delete
$ kubectl delete pvc --force --grace-period=0 <PVC name> |
4. Edit PV <If the IOPS for Endurance was also changed, change the storage-class as well >
Modify the following 2 parts to the expanded capacity and save:
labels > CapacityGb
spec > capacity > storage
Delete the claimRef
$ kubectl edit pv <PV name> ... labels: CapacityGb: "30" ... spec: ... capacity: storage: 30Gi ... |
5. PV patch
$ kubectl patch pv <PV name> -p '{"metadata": {"annotations":{"ibm.io/autofix-resizefs":"true"}}}' |
6. PVC create
Create the PVC using the backed-up PVC yaml.
$ kubectl create -f <Saved PVC filename>.yaml |
[When the Reclaim Policy of the PV is “Delete”]
<Warning> If the PVC is deleted first and not in the order below, the storage will be deleted.
1. PV, PVC backup
$ kubectl get pv <PV name> -o yaml > <desired filename>.yaml $ kubectl get pvc <PVC name> -o yaml > <desired filename>.yaml |
2. Edit PV yaml <If the IOPS for Endurance was also changed, change the storage-class as well>
Modify the following 2 parts to the expanded capacity and save:
labels > CapacityGb
spec > capacity > storage
Delete the claimRef section
$ vi <Saved PV filename>.yaml ... labels: CapacityGb: "30" ... spec: ... capacity: storage: 30Gi ... |
Edit PVC yaml file <If the IOPS for Endurance was also changed, change the storage-class as well>
Modify the following 3 parts to the expanded capacity and save:
metadata > annotation > kubectl.kubernetes.io/last-applied-configuration
spec > resources > requests > storage
status > capacity > storage
$ vi <Saved PVC filename>.yaml ... kubectl.kubernetes.io/last-applied-configuration: | {"apiVersion":"v1","kind":"PersistentVolumeClaim","metadata":{"annotations":{"kubernetes.io/change-cause":"kubectl apply --filename=k8s/prod/pvc.yaml --namespace=zcp-system --record=true","volume.beta.kubernetes.io/storage-class":"ibmc-block-bronze"},"labels":{"billingType":"monthly"},"name":"pvc-test","namespace":"zcp-system"},"spec":{"accessModes":["ReadWriteOnce"],"resources":{"requests":{"storage":"30Gi"}}}}... spec: ... resources: requests: storage: 20Gi ... status: ... capacity: storage: 20Gi ... |
3. PV Delete
$ kubectl delete pv --force --grace-period=0 <PV name>
# If the status remains as Terminating even after executing the above command, execute the patch belw $ kubectl patch pv <pvc name> -p '{"metadata":{"finalizers":null}}' |
4. PVC Delete
$ kubectl delete pvc --force --grace-period=0 <PVC name> |
5. PV create
Create the PV using the backed-up PV yaml.
$ kubectl create -f <Saved PV filename>.yaml |
6. PVC create
Create the PVC using the backed-up PVC yaml.
$ kubectl create -f <Saved PVC filename>.yaml |
7. PV patch
$ kubectl patch pv <PV name> -p '{"metadata": {"annotations":{"ibm.io/autofix-resizefs":"true"}}}' |
How to expand capacity via kubectl
Expanding capacity in PVC
Edit the PVC of the PV you want to modify, change the size (e.g., from 5GB to 6GB), and save.
$ kubectl edit pvc zcp-oidc-postgresql apiVersion: v1 kind: PersistentVolumeClaim ... spec: ... resources: requests: storage: 5Gi ... |
Verify if the expansion has been applied
Check via kubectl CLI
Check PVC capacity
$ kubectl get pvc -w NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE elasticsearch-data-test-elasticsearch-data-test-0 Bound pvc-xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx 200Gi RWO ibmc-block-retain-silver 21h elasticsearch-data-test-elasticsearch-data-test-1 Bound pvc-xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx 200Gi RWO ibmc-block-retain-silver 21h elasticsearch-data-test-elasticsearch-data-test-2 Bound pvc-xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx 200Gi RWO ibmc-block-retain-silver 21h elasticsearch-data-test-elasticsearch-data-test-2 Bound pvc-xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx 220Gi RWO ibmc-block-retain-silver 21h |
Check PV capacity
$ kubectl get pv NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE pvc-xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx 220Gi RWO Retain Bound zcp-system/elasticsearch-data-test-elasticsearch-data-test-2 ibmc-block-retain-silver 21h |
Restart the connected pod
Enter the pod and verify if the modified capacity has been applied.
$ kubectl exec -it elasticsearch-data-test-2 bash [root@elasticsearch-data-test-2 elasticsearch]# df -h Filesystem Size Used Avail Use% Mounted on ... /dev/mapper/3600a09803830446d463f4c454857636c 216G 60M 216G 1% /usr/share/elasticsearch/data ... |
Reference page
https://kubernetes.io/blog/2018/07/12/resizing-persistent-volumes-using-kubernetes/
https://kubernetes.io/docs/concepts/storage/persistent-volumes/#expanding-persistent-volumes-claims
How to Expand File Storage on AWS
There is no need to expand separately.
In AWS, file Storage is not created as individual PVs, but as a single EFS.
When you create a file storage, a folder is created inside the EFS, and if the capacity set at the time of creation is exceeded, it is automatically expanded to the increased capacity. For reference, billing is based on the total capacity of the EFS.
Azure
How to Expand Block Storage on Azure
<Caution> Before expanding the capacity, if there is a pod connected to the PV, you must terminate it first.
1. In Azure Console (https://portal.azure.com/ ), select Resource groups → select AKS resource group → search by PV name and select it → check the capacity.
2. Click Settings > Size + performance.
Change the disk size to the desired capacity and click the [Resize] button.
<Caution> Regardless of the amount of disk space used, you will be charged for the provisioned disk.
For example, a 200GiB disk is provisioned as a 256GiB disk, so you will be charged for the provisioned 256GiB.
3. Check the message confirming that the change is complete.
4. Overview에서 변경된 용량을 확인합니다.
If there is a pod connected to the PV that you stopped earlier, please restart it.
Change the defined capacity of PV and PVC to the expanded size
This method is needed to make the expanded capacity visible when checking with kubectl get pv or kubectl get pvc.
You do not need to do this if you do not mind seeing the previous capacity.
[If the Reclaim Policy of the PV is Retain ]
1. PVC Backup
Back up the PVC of the corresponding PV.
$ kubectl get pvc <PVC name> -o yaml > <desired filename>.yaml |
2. Modify the PVC yaml file <If you also changed the IOPS of Endurance, change the storage-class as well>
Change the following three parts to the expanded capacity and save:
metadata > annotation > kubectl.kubernetes.io/last-applied-configuration
spec > resources > requests > storage
status > capacity > storage
$ vi <Saved PVC filename>.yaml ... kubectl.kubernetes.io/last-applied-configuration: | {"apiVersion":"v1","kind":"PersistentVolumeClaim","metadata":{"annotations":{"kubernetes.io/change-cause":"kubectl apply --filename=k8s/prod/pvc.yaml --namespace=zcp-system --record=true","volume.beta.kubernetes.io/storage-class":"ibmc-block-retain-bronze"},"labels":{"billingType":"monthly"},"name":"pvc-test","namespace":"zcp-system"},"spec":{"accessModes":["ReadWriteOnce"],"resources":{"requests":{"storage":"30Gi"}}}} ... spec: ... resources: requests: storage: 20Gi ... status: ... capacity: storage: 30Gi ... |
3. PVC Delete
$ kubectl delete pvc --force --grace-period=0 <PVC name> |
4. Modify the PV <If you also changed the IOPS of Endurance, change the storage-class as well>
Change the following two parts to the expanded capacity and save:
labels > CapacityGb
spec > capacity > storage
Delete the claimRef part
$ kubectl edit pv <PV name> ... labels: CapacityGb: "30" ... spec: ... capacity: storage: 30Gi ... |
5. PV patch
$ kubectl patch pv <PV name> -p '{"metadata": {"annotations":{"ibm.io/autofix-resizefs":"true"}}}' |
6. PVC create
Create the PVC using the previously backed-up PVC yaml.
$ kubectl create -f <Saved PVC filename>.yaml |
[If the Reclaim Policy of the PV is Delete]
<Caution> If you delete the PVC first instead of following the order below, the Storage will be deleted
1. PV, PVC backup
$ kubectl get pv <PV name> -o yaml > <desired filename>.yaml $ kubectl get pvc <PVC name> -o yaml > <desired filename>.yaml |
2. Modify the PV yaml <If you also changed the IOPS of Endurance, change the storage-class as well>
Change the following two parts to the expanded capacity and save:
labels > CapacityGb
spec > capacity > storage
Delete the claimRef part
$ vi <Saved PV filename>.yaml ... labels: CapacityGb: "30" ... spec: ... capacity: storage: 30Gi ... |
3. Modify the PVC yaml file <If you also changed the IOPS of Endurance, change the storage-class as well>
Change the following three parts to the expanded capacity and save:
metadata > annotation > kubectl.kubernetes.io/last-applied-configuration
spec > resources > requests > storage
status > capacity > storage
$ vi <Saved PVC filename>.yaml ... kubectl.kubernetes.io/last-applied-configuration: | {"apiVersion":"v1","kind":"PersistentVolumeClaim","metadata":{"annotations":{"kubernetes.io/change-cause":"kubectl apply --filename=k8s/prod/pvc.yaml --namespace=zcp-system --record=true","volume.beta.kubernetes.io/storage-class":"ibmc-block-bronze"},"labels":{"billingType":"monthly"},"name":"pvc-test","namespace":"zcp-system"},"spec":{"accessModes":["ReadWriteOnce"],"resources":{"requests":{"storage":"30Gi"}}}}... spec: ... resources: requests: storage: 20Gi ... status: ... capacity: storage: 20Gi ... |
4. PV Delete
$ kubectl delete pv --force --grace-period=0 <PV name>
# If the status remains Terminating after executing the above command, execute the patch belw $ kubectl patch pv <pvc name> -p '{"metadata":{"finalizers":null}}' |
5. PVC Delete
$ kubectl delete pvc --force --grace-period=0 <PVC name> |
6. PV create
Create the PV using the previously backed-up PV yaml.
$ kubectl create -f <Saved PV filename>.yaml |
7. PVC create
Create the PVC using the previously backed-up PVC yaml.
$ kubectl create -f <Saved PVC filename>.yaml |
8. PV patch
$ kubectl patch pv <PV name> -p '{"metadata": {"annotations":{"ibm.io/autofix-resizefs":"true"}}}' |
How to Expand File Storage on Azure
<Reference> Block Storage can also be expanded using the method below.
Capacity expansion from PVC
Edit the PVC of the PV you want to change and increase the capacity (20GB → 22GB), then save.
$ kubectl edit pvc elasticsearch-data-elasticsearch-data-2 apiVersion: v1 kind: PersistentVolumeClaim ... spec: ... resources: requests: storage: 200Gi ... |
Check whether the capacity has been changed to the expanded size
Check using kubectl CLI
Check PVC capacity
$ kubectl get pvc NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE ... zcp-git-gitea Bound pvc-4b3376db-4961-42a5-9b66-8b336372e744 22Gi RWX file-standard 448d ... |
Check PV capacity
$ kubectl get pv NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE pvc-xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx 220Gi RWO Retain Bound zcp-system/elasticsearch-data-test-elasticsearch-data-test-2 ibmc-block-retain-silver 21h |
Check inside the pod
bash-5.0# df -h Filesystem Size Used Avail Use% Mounted on ... //f8dc90c65c805484399c8b0.file.core.windows.net/kubernetes-dynamic-pvc-4b3376db-4961-42a5-9b66-8b336372e744 22.0G 64.0K 22.0G 0% /data ... |
IBM
Check whether the allowVolumeExpansion setting is enabled in the storage class of the PV you want to expand.
allowVolumeExpansion: true
$ kubectl get storageclass ibmc-block-bronze -o yaml allowVolumeExpansion: true apiVersion: storage.k8s.io/v1 kind: StorageClass ... |
If allowVolumeExpansion is enabled
Capacity expansion from PVC
Edit the PVC of the PV you want to expand, increase the capacity (200GB → 220GB), and save.
$ kubectl edit pvc elasticsearch-data-elasticsearch-data-2 apiVersion: v1 kind: PersistentVolumeClaim ... spec: ... resources: requests: storage: 200Gi ... |
Check whether the capacity has been changed to the expanded size
Check using the kubectl CLI:
Check PVC capacity
$ kubectl get pvc -w NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE elasticsearch-data-test-elasticsearch-data-test-0 Bound pvc-xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx 200Gi RWO ibmc-block-retain-silver 21h elasticsearch-data-test-elasticsearch-data-test-1 Bound pvc-xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx 200Gi RWO ibmc-block-retain-silver 21h elasticsearch-data-test-elasticsearch-data-test-2 Bound pvc-xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx 200Gi RWO ibmc-block-retain-silver 21h elasticsearch-data-test-elasticsearch-data-test-2 Bound pvc-xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx 220Gi RWO ibmc-block-retain-silver 21h |
Check PV capacity
$ kubectl get pv NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE pvc-xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx 220Gi RWO Retain Bound zcp-system/elasticsearch-data-test-elasticsearch-data-test-2 ibmc-block-retain-silver 21h |
Check inside the pod
$ kubectl exec -it elasticsearch-data-test-2 bash [root@elasticsearch-data-test-2 elasticsearch]# df -h Filesystem Size Used Avail Use% Mounted on ... /dev/mapper/3600a09803830446d463f4c454857636c 216G 60M 216G 1% /usr/share/elasticsearch/data ... |
Check in IBM console
1. Check the VolumeID of the PV
$ kubectl get pv -o yaml pvc-b4e6876b-011c-48c1-9a9b-d84172078d8f apiVersion: v1 kind: PersistentVolume ... spec: ... flexVolume: ... options: ... VolumeID: "131379026" ... |
2. Check the changed capacity in the IBM console
If allowVolumeExpansion is not enabled
Change capacity in IBM console
1. In the IBM Cloud™ console (https://cloud.ibm.com), click Classic Infrastructure > Storage > Block Storage.
2. From the list, select the LUN (Logical Unit Number) and click Actions > Modify LUN.
3. Enter the new storage size in GB.
You can only set it larger than the current PV size, and it can be expanded up to 12,000GB (12TB).
4. Review the options and the new pricing.
You can change the storage class applied to the current PV.
5. Check the box for “I have read the Master Service Agreement...” and click Order.
6. After about 5 minutes, check whether the changed capacity has been applied.
Change the pod capacity after expansion
After performing the above tasks, the actual storage will be expanded, but in the connected pod, it will still show the previous capacity.
If you apply the patch below to the PV and restart the connected pod, it will connect with the expanded capacity.
$ kubectl patch pv <PV name> -p '{"metadata": {"annotations":{"ibm.io/autofix-resizefs":"true"}}}' |
Change the defined capacity of PV and PVC to the expanded size
This method is needed to make the expanded capacity visible when checking with kubectl get pv or kubectl get pvc.
You do not need to do this if you do not mind seeing the previous capacity.
[If the Reclaim Policy of the PV is Retain]
1. PVC Backup
Back up the PVC of the corresponding PV.
$ kubectl get pvc <PVC name> -o yaml > <desired filename>.yaml |
2. Modify the PVC yaml file <If you also changed the IOPS of Endurance, change the storage-class as well>
Change the following three parts to the expanded capacity and save:
metadata > annotation > kubectl.kubernetes.io/last-applied-configuration
spec > resources > requests > storage
status > capacity > storage
$ vi <Saved PVC filename>.yaml ... kubectl.kubernetes.io/last-applied-configuration: | {"apiVersion":"v1","kind":"PersistentVolumeClaim","metadata":{"annotations":{"kubernetes.io/change-cause":"kubectl apply --filename=k8s/prod/pvc.yaml --namespace=zcp-system --record=true","volume.beta.kubernetes.io/storage-class":"ibmc-block-retain-bronze"},"labels":{"billingType":"monthly"},"name":"pvc-test","namespace":"zcp-system"},"spec":{"accessModes":["ReadWriteOnce"],"resources":{"requests":{"storage":"30Gi"}}}} ... spec: ... resources: requests: storage: 20Gi ... status: ... capacity: storage: 30Gi ... |
3. PVC Delete
$ kubectl delete pvc --force --grace-period=0 <PVC name> |
4. Modify the PV <If you also changed the IOPS of Endurance, change the storage-class as well>
Change the following two parts to the expanded capacity and save:
labels > CapacityGb
spec > capacity > storage
Delete the claimRef part
$ kubectl edit pv <PV name> ... labels: CapacityGb: "30" ... spec: ... capacity: storage: 30Gi ... |
5. PV patch
$ kubectl patch pv <PV name> -p '{"metadata": {"annotations":{"ibm.io/autofix-resizefs":"true"}}}' |
6. PVC create
Create the PVC using the previously backed-up PVC yaml.
$ kubectl create -f <Saved PVC filename>.yaml |
[If the Reclaim Policy of the PV is Delete]
<Caution> If you delete the PVC first instead of following the order below, the Storage will be deleted.
1. PV, PVC backup
$ kubectl get pv <PV name> -o yaml > <desired filename>.yaml $ kubectl get pvc <PVC name> -o yaml > <desired filename>.yaml |
2. Modify the PV yaml <If you also changed the IOPS of Endurance, change the storage-class as well>
Change the following two parts to the expanded capacity and save:
labels > CapacityGb
spec > capacity > storage
Delete the claimRef part
$ vi <Saved PV filename>.yaml ... labels: CapacityGb: "30" ... spec: ... capacity: storage: 30Gi ... |
3. Modify the PVC yaml file <If you also changed the IOPS of Endurance, change the storage-class as well>
Change the following three parts to the expanded capacity and save:
metadata > annotation > kubectl.kubernetes.io/last-applied-configuration
spec > resources > requests > storage
status > capacity > storage
$ vi <Saved PVC filename>.yaml ... kubectl.kubernetes.io/last-applied-configuration: | {"apiVersion":"v1","kind":"PersistentVolumeClaim","metadata":{"annotations":{"kubernetes.io/change-cause":"kubectl apply --filename=k8s/prod/pvc.yaml --namespace=zcp-system --record=true","volume.beta.kubernetes.io/storage-class":"ibmc-block-bronze"},"labels":{"billingType":"monthly"},"name":"pvc-test","namespace":"zcp-system"},"spec":{"accessModes":["ReadWriteOnce"],"resources":{"requests":{"storage":"30Gi"}}}}... spec: ... resources: requests: storage: 20Gi ... status: ... capacity: storage: 20Gi ... |
4. PV Delete
$ kubectl delete pv --force --grace-period=0 <PV name>
# If the status remains as Terminating even after executing the above command, execute the patch belw $ kubectl patch pv <pvc name> -p '{"metadata":{"finalizers":null}}' |
5. PVC Delete
$ kubectl delete pvc --force --grace-period=0 <PVC name> |
6. PV create
Create the PV using the previously backed-up PV yaml.
$ kubectl create -f <Saved PV filename>.yaml |
7. PVC create
Create the PVC using the previously backed-up PVC yaml.
$ kubectl create -f <Saved PVC filename>.yaml |
8. PV patch
$ kubectl patch pv <PV name> -p '{"metadata": {"annotations":{"ibm.io/autofix-resizefs":"true"}}}' |