Skip to content

Clarify definition of Capacity in the spec #338

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
j-griffith opened this issue Nov 16, 2018 · 1 comment · May be fixed by #587
Open

Clarify definition of Capacity in the spec #338

j-griffith opened this issue Nov 16, 2018 · 1 comment · May be fixed by #587

Comments

@j-griffith
Copy link

j-griffith commented Nov 16, 2018

There are some questions that have come up around the definition of capacity and how it differs between raw and file-system based provisioners. There may also be some misinterpretation on the impact attach/mkfs might have on this reported value.

It would be good to explicitly define these things in the spec so there's no confusion.

Just to expand on this here's what my assumption has been, and it seem they may not match with others thus they may be incorrect, or need clarification in the spec:

In the case of a block device:

  • User requests a PVC with capacity of 1 Gig
  • Storage backend provides a volume that will have a raw capacity of 1 Gig
  • If formatted and attached to a container in a POD, the actually usable filesystem capacity will be less than the raw capacity requested/reported of 1 Gig.
@saad-ali
Copy link
Member

Good point. Worth clarifying.

k8s-ci-robot pushed a commit to kubernetes/website that referenced this issue Mar 25, 2025
Though this is not explicitly stated, it seems acceptable that
once a provider builds a filesystem on top of a block device,
some writeable capacity is lost:
container-storage-interface/spec#338

Signed-off-by: Alex Kalenyuk <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants