Closed sazzy4o closed 10 months ago
@BigVan cc
recently we have been considering how to adjust overlaybd image size. it should support extending the virtual size of overlaybd, and resizing the filesystem is also needed. maybe we can pass the image size u need through CRI annotations:
// CRIOverlaybdSize is the device size of overlaybd. extend support only.
CRIOverlaybdSize = "containerd.io/snapshot/cri.overlaybd.vsize"
// CRIOverlaybdFsQuota use for shrinking FS size through prjquota. runc support only.
CRIOverlaybdFsQuota = "containerd.io/snapshot/cri.overlaybd.fsquota"
it seems containerd can't pass pod annotations to the container now... so somebody have any idea?
one more thing is, Overlaybd can select different writable layers and fsquota per container if the snapshotter can get container labels from containerd. If different runtime containers on a host, they can select different writable types. For example, using overlayfs in runc and passing the overlaybd RW-device through virtio-blk in Kata will have a better performance than passing Rootfs dir through virtio-fs.
@fuweid @AkihiroSuda
Thanks @BigVan! I'll have a look this week to see if there is a way to pass annotations or another easy way to specify size via the cli
If anyone suggestions to the best way of doing this, I would love to hear
This is supported at the time that an image in built in this PR: https://github.com/containerd/accelerated-container-image/pull/256
What is the version of your Accelerated Container Image
v1.0.1
What would you like to be added?
When
rwMode
isdev
set a block device is created with each container allowing the disk space and inodes to be constrained for each containerCurrently the device size/quota is hard coded at 64 GiB See here
There should be a way either in the config file or cli (ctr, nerdctl, etc.) to pass in the device size
Why is this needed for Accelerated Container Image?
It is possible that a containers can use too much disk space and cause other containers or the host to have errors. Therefore needs to be a way to constrain disk space (and inodes). There are also cases where much less or much more than 64 GiB might be needed for a container.
This change is important for reliability
(I am happy to implement if there is interest)
Are you willing to submit PRs to contribute to this feature?