Context
Increasing a PersistentVolumeClaim's requested size is the start of a storage change, not proof that the application can use more space. The storage driver must expand the backing volume, and a filesystem volume may also need filesystem expansion. A dashboard showing a larger claim can therefore coexist with an application still reporting a full disk.
Imagine an illustrative database Pod whose claim was increased during an incident. The administrator sees the new request in YAML, but writes still fail. Repeatedly increasing the number adds confusion. The next step is to determine which stage completed and which stage is waiting, using the claim, driver, and mounted filesystem evidence.
Verify expansion support before editing
Kubernetes documents that PVC expansion requires an eligible storage class with allowVolumeExpansion enabled and a volume driver that supports the operation. Filesystem expansion has its own support requirements and may occur online or during Pod startup. Directly editing a PV's reported capacity can interfere with the normal resize process. 1
Record storage class, CSI driver and version, volume mode, filesystem type, access mode, and the application's mount path. Consult the driver's supported procedure. A raw block volume and a filesystem mount require different acceptance checks, so establish which one the workload actually uses.
Preserve a recovery point and capacity evidence
For important data, verify the appropriate backup or recovery procedure before making a storage change. Record current claim size, backing volume size, filesystem capacity, used bytes, and free inodes where relevant. Include the rate of growth so the selected increase provides meaningful headroom.
A volume expansion is generally not a reversible experiment in the same way as changing a timeout. Do not assume that shrinking it later is supported. Choose the target size deliberately and confirm quota, cost, and provider limits. Keep the data owner informed about any required interruption or restart.
Follow the request through each layer
After requesting a larger PVC, inspect its status, conditions, and events. Look for controller resize progress or failure, then inspect the storage driver's relevant logs through the approved access path. Confirm the cloud or storage platform reports the intended backing capacity.
If the backing volume has grown but the filesystem has not, investigate the node-side resize stage and the driver's documented requirements. Do not delete and recreate the claim as a generic repair. Claim deletion and reclaim policy can affect the data lifecycle and make a manageable resize issue much harder to recover.
Check the exact path the application writes
Inside an appropriate diagnostic context, verify the mount and filesystem capacity for the application's actual data directory. A command run against the container root filesystem answers a different question from one run against the persistent mount. Confirm that the expected volume is mounted where the application configuration says it is.
Also inspect quotas, inodes, and application-specific storage limits. More block capacity will not necessarily resolve an inode shortage or a per-user quota. If a database has its own file or tablespace configuration, validate that layer separately. The storage stack can contain several independent definitions of available capacity.
Coordinate restarts only when the procedure requires them
Some combinations support online filesystem expansion; others need a documented Pod restart or remount path. Confirm the actual requirement before interrupting the workload. For replicated applications, coordinate the restart with quorum, readiness, and disruption budgets rather than treating every Pod as interchangeable.
Avoid editing StatefulSet storage templates and assuming every existing claim will immediately follow the new value. Existing claims and controller templates have distinct lifecycle behaviour. Use the supported procedure for the deployed controller and Kubernetes version, and keep the change record clear about which claims were individually expanded.
Handle failed expansion without losing state
If a request exceeds a provider limit or quota, preserve the error and identify the supported recovery procedure. Do not repeatedly change PV and PVC fields until their displayed values match. Matching metadata can conceal the fact that no backing resize occurred.
Use the documented failure-recovery approach for the cluster version and driver. Escalate with the resource identifiers, requested size, actual backing size, conditions, and driver evidence. That package gives the storage owner a concrete problem to solve without exposing application data or requiring a broad administrative session.
Validate real application writes
After capacity appears at the mounted filesystem, perform a safe application-level write and readback appropriate to the workload. Confirm normal error rates, latency, and background processing. For a database, use an approved transaction rather than creating arbitrary files in its managed data directory.
An illustrative acceptance record might show the requested size, provider size, filesystem size, free capacity, and a successful business operation. These observations establish different stages of completion. Keep the old and new values together so later growth investigations have a reliable baseline.
Add a sustainable capacity policy
Alert early enough to perform a controlled expansion before writes fail. Track growth rate and projected exhaustion as well as a static percentage. Include inode or quota monitoring where those are relevant. A large but rapidly growing dataset can need attention while its percentage-used graph still looks comfortable.
A focused operator exercise: A three-layer resize acceptance example
For a test claim, record the requested size, storage-provider volume size, and mounted filesystem capacity before expansion. Perform the supported resize and update each observation only when that layer actually changes. If a node-side step is required, follow the driver's documented procedure and record the interruption separately.
Finally, perform a harmless application-owned write and readback at the real data path. The acceptance table should show all three capacity values and the business check rather than one larger YAML field. Include a check that the volume is still mounted at the intended path, because an apparently writable fallback directory can conceal a missing persistent mount.
Quick diagnostic map
| Evidence | Review | Acceptance boundary |
|---|---|---|
| PVC request | Compare requested and reported capacity | Confirm expansion is allowed |
| Storage backend | Inspect driver events and volume size | Verify backend completion |
| Filesystem view | Check usable size inside the workload | Follow the driver-supported resize sequence |
Frequently asked questions
Does a larger PVC request prove the disk is ready? No. Verify the backing volume, mounted filesystem, and application behaviour.
Clouvenix can review the full resize path and produce a storage runbook that names the driver requirements, recovery safeguards, and evidence needed to declare the application ready.
For a scoped review of this workflow, discuss the relevant Clouvenix engineering service.