Skip to main content
Version: main

Volume Resize

Local PV Rawfile supports online volume expansion - the backing file, loop device, and filesystem are grown live with no pod restart required. Shrinking is not supported.

Requirements​

  • Resize must be enabled in the chart (default): capabilities.resize.enabled=true
  • The StorageClass must set allowVolumeExpansion: true
  • Online filesystem growth is supported for ext4, xfs, and btrfs
  • Sufficient free capacity must exist in the volume's storage pool on its node

StorageClass Configuration​

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: rawfile-localpv
provisioner: rawfile.csi.openebs.io
volumeBindingMode: WaitForFirstConsumer
reclaimPolicy: Delete
allowVolumeExpansion: true
parameters:
  csi.storage.k8s.io/fstype: ext4

Expand a Volume​

Edit the PVC's spec.resources.requests.storage to the new (larger) size:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: app-data
spec:
  storageClassName: rawfile-localpv
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 20Gi    # was 10Gi
kubectl apply -f pvc.yaml

Or patch in place:

kubectl patch pvc app-data \
  -p '{"spec":{"resources":{"requests":{"storage":"20Gi"}}}}'

Monitor the Expansion​

Watch for the capacity to update:

kubectl get pvc app-data -w
# NAME       STATUS   VOLUME      CAPACITY   ACCESS MODES   STORAGECLASS
# app-data   Bound    pvc-xxxxx   10Gi       RWO            rawfile-localpv
# app-data   Bound    pvc-xxxxx   20Gi       RWO            rawfile-localpv

Check events and conditions if it takes longer than expected:

kubectl describe pvc app-data

Under the hood, the csi-resizer sidecar calls the controller, which forwards the request to the node that owns the volume. The node grows the backing file, resizes the loop device, and expands the filesystem online.

Verify Inside the Pod​

kubectl exec app -- df -hT /data
# Filesystem     Type  Size  Used Avail Use% Mounted on
# /dev/loop3     ext4   20G  1.1G   18G   6% /data

No pod restart is needed - the new capacity is visible immediately after the resize completes.

Block Mode Volumes​

Block volumes (volumeMode: Block) are also expandable. If the volume is currently unstaged (no pod consuming it), only the backing file is grown; node-side expansion is deferred until the volume is next attached. The application inside the pod is responsible for recognizing the larger device.

Limitations​

ItemStatus
Online expansion (ext4/xfs/btrfs) while pod is runningSupported
ShrinkingNot supported - requests to reduce size are rejected by Kubernetes
Expansion beyond pool free spaceFails with Not enough disk space

Troubleshooting​

SymptomFix
PVC capacity never updatesCheck: allowVolumeExpansion: true on StorageClass, capabilities.resize.enabled=true in chart, controller deployment is running: kubectl -n openebs logs deploy/<release>-controller.
Not enough disk spaceThe pool on the volume's node lacks free capacity. Free space or grow the underlying disk. Monitor: rawfile_pool_remaining_capacity_bytes.
Resizing capabilities are disabledSet capabilities.resize.enabled=true and upgrade the Helm release.
Filesystem size unchanged but PV shows new sizeNode-side expansion pending - ensure the node plugin is healthy; kubelet triggers NodeExpandVolume on the mounted node.

Support​

If you encounter issues or have a question, file a Github issue, or talk to us on the #openebs channel on the Kubernetes Slack server.

See Also​