Problem
Running multi-tenant Sysbox (systemd-in-container) workloads on a dstack CVM provisioned with --fs ext4 (native ext4 on /dev/mapper/dstack_data_disk). The workloads themselves run fine on the current kernel (the existing dstack-sysbox.cfg fragments cover that).
What's missing is any way to enforce per-directory disk quotas on the ext4 data disk, so one workload cannot fill the shared disk and starve the others. The standard mechanism is ext4 project quotas (tune2fs -O quota,project + per-directory project IDs), but the 6.9.0-dstack kernel is built without quota support:
EXT4-fs: prjquota option not supported
EXT4-fs (dm-1): The kernel was not built with CONFIG_QUOTA and CONFIG_QFMT_V2
Reproduction: on an --fs ext4 CVM, set the quota features offline with tune2fs (accepted), then remount with -o prjquota → refused with the messages above.
Related gap: the kernel has no loop block driver at all (modprobe loop → Module loop not found in directory /lib/modules/6.9.0-dstack, no /dev/loop-control), so filesystem-image-based alternatives are unavailable too.
Requested change
Add to meta-dstack/recipes-kernel/linux/files/dstack-sysbox.cfg (or a new dstack-quota.cfg + .scc wired the same way):
# Per-directory ext4 project quotas for multi-tenant workloads.
CONFIG_QUOTA=y
CONFIG_QFMT_V2=y
Optional, at the same time:
plus kernel-module-loop in dstack-rootfs-base.inc IMAGE_INSTALL (the established pattern used for tun/fuse/nft modules), or =y to avoid the rootfs change.
Both are normal promptable Kconfig symbols, settable from a .cfg fragment — same mechanism as the existing sysbox fragment.
Impact
CONFIG_QUOTA/CONFIG_QFMT_V2 are mature core-VFS features, inert unless a filesystem is mounted with quota options; no behavior change for existing ZFS-based CVMs.- Quota userspace tooling can live entirely in the workload's own images; enforcement is in-kernel. Nothing else in the dstack rootfs needs to change.
- Loop (
=m) loads only on demand.
Problem
Running multi-tenant Sysbox (systemd-in-container) workloads on a dstack CVM provisioned with
--fs ext4(native ext4 on/dev/mapper/dstack_data_disk). The workloads themselves run fine on the current kernel (the existingdstack-sysbox.cfgfragments cover that).What's missing is any way to enforce per-directory disk quotas on the ext4 data disk, so one workload cannot fill the shared disk and starve the others. The standard mechanism is ext4 project quotas (
tune2fs -O quota,project+ per-directory project IDs), but the6.9.0-dstackkernel is built without quota support:Reproduction: on an
--fs ext4CVM, set the quota features offline withtune2fs(accepted), then remount with-o prjquota→ refused with the messages above.Related gap: the kernel has no loop block driver at all (
modprobe loop→Module loop not found in directory /lib/modules/6.9.0-dstack, no/dev/loop-control), so filesystem-image-based alternatives are unavailable too.Requested change
Add to
meta-dstack/recipes-kernel/linux/files/dstack-sysbox.cfg(or a newdstack-quota.cfg+.sccwired the same way):Optional, at the same time:
plus
kernel-module-loopindstack-rootfs-base.incIMAGE_INSTALL(the established pattern used for tun/fuse/nft modules), or=yto avoid the rootfs change.Both are normal promptable Kconfig symbols, settable from a
.cfgfragment — same mechanism as the existing sysbox fragment.Impact
CONFIG_QUOTA/CONFIG_QFMT_V2are mature core-VFS features, inert unless a filesystem is mounted with quota options; no behavior change for existing ZFS-based CVMs.=m) loads only on demand.