# Persistent Volume (PV) shrinking

**URL:** <https://discuss.kubernetes.io/t/persistent-volume-pv-shrinking/20175>\
**Category:** General Discussions\
**Created:** [May 28, 2022, 12:09am UTC](https://discuss.kubernetes.io/t/persistent-volume-pv-shrinking/20175 "2022-05-28T00:09:53Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![ksa](https://avatars.discourse-cdn.com/v4/letter/k/c77e96/32.png) [@ksa](https://discuss.kubernetes.io/u/ksa)\
**Post date:** [May 28, 2022, 12:09am UTC](https://discuss.kubernetes.io/t/persistent-volume-pv-shrinking/20175/1 "2022-05-28T00:09:53Z")

</div>

I’d like to understand a design decision behind not allowing PVC/PV shrinking. I hope there is someone who was involved and can provide me with insights on this. If there is some publicly accessible information on the topic, I’d be grateful for the links.

Was it a conscious decision to not allow shrinking? Is it some historical-only limitation connected to the persistent volume types available at the time?

Not allowing shrinking PVC has no sense in my opinion. If PV provider doesn’t allow shrinking then shrinking PVC is just a no-action because bind PV already satisfy both old and new (lower) capacity requirement. At the moment the CSIs we use could easily support shrinking and not doing so just because of K8s API limitations.

### Cluster information:

Kubernetes version: 1.23.5  
Cloud being used: bare-metal  
Installation method: kubeadm + extras  
Host OS:  
CNI and version: cilium  
CRI and version: containerd  
CSI: TopoLS, SeaweedFS