Add note about possibly lower available capacity on MountVolume volumes #587
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
When a CreateVolume request is handled by an SP, the requested capacity does not include any potential overhead of filesystem metadata. This can cause confusion, as users may not be able to store data up to the amount of the requested size of the volume. The SP is expected to provision a volume following the capacity_range request, but the SP may not know how much storage for filesystem metadata will be required (depends on filesystem type and enabled features). In these cases, the usable capacity of the volume will be slightly smaller than the requested capacity.
bswartz
requested changes
Oct 8, 2025
| If CO requests a volume to be created from existing snapshot or volume and the requested size of the volume is larger than the original snapshotted (or cloned volume), the Plugin can either refuse such a call with `OUT_OF_RANGE` error or MUST provide a volume that, when presented to a workload by `NodePublish` call, has both the requested (larger) size and contains data from the snapshot (or original volume). | ||
| Explicitly, it's the responsibility of the Plugin to resize the filesystem of the newly created volume at (or before) the `NodePublish` call, if the volume has `VolumeCapability` access type `MountVolume` and the filesystem resize is required in order to provision the requested capacity. | ||
|
|
||
| NOTE: The requested and reported sizes for a volume refer to the raw volume size that the SP allocated for the volume. Volumes with an `access_type` of `MountVolume` MAY have a slightly reduced available capacity due to the metadata that the filesystem stores on the volume. The underlying volume when used in `access_mode` with a value of `BlockVolume` MUST match the specified `capacity_range` request. |
There was a problem hiding this comment.
This is a useful note, but I don't agree with the "slightly" characterization. In reality it may be significantly less, and the sad truth is we don't enforce any limit. We should use more precise language here. Perhaps:
NOTE: The requested and reported sizes for a volume refer to the raw volume size that the SP allocated for the volume. Volumes with an access_type of MountVolume will have less available capacity due to the overhead of filesystem metadata (exact amount depends on filesystem). The underlying volume when used in access_mode with a value of BlockVolume MUST match the specified capacity_range request.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What type of PR is this?
Documentation change, setting expectations of the
capacity_rangesizes inCreateVolumeand other RPCs.What this PR does / why we need it:
Users have been confused about provisioned volumes that were slightly smaller than what they requested.
Which issue(s) this PR fixes:
Fixes #338
Special notes for your reviewer:
A similar note was added through kubernetes/website#50146.
Does this PR introduce an API-breaking change?: