containerd / containerd/containerd

Filesystem quotas

Open
#759 23 comments 12 reactions 1 assignee Claimed by @pacoxu View on GitHub
exp/expert kind/feature kind/help-wanted status/roadmapped
Dominant language
Go
Stars
21.3k
Forks
4.1k
Avg merge
2d 4h
Merged PRs (30d)
92

Description

Following up the discussion from the last containerd summit:

https://github.com/containerd/containerd/blob/6ae973362af4b9ae27fb335efba6b5e508bc1752/docs/dockercon-summit.md#discussion-points

How to support per-container fs quotas? The implementation of quotas (usually called project quotas) is tied to the specific implementation of the `Snapshotter` being used.

* What is the right abstraction to support different project quota implementations (`brtfs`, `overlay+xfs`, `overlay+ext4`, and maybe in the future `zfs`, `devicemapper` and others since anyone can implement `Snapshotter`)?
* What is the right granularity for quotas? Some project quota implementations allow volumes and container writeable layers to be in the same quota group, and share the same quota limit. Is it something that need to be supported, or volumes will always be in different quota groups, managed completely outside containerd?
* During the discussion, encouraging read-only container filesystems was mentioned, and forcing people to use volumes for R/W directories, with quotas being managed by external volume managers. I agree this would be ideal, but is it even possible to force read-only rootfs for everyone?

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.