Hi, from the perspective of an application developer, this approach would be perfect if we could have some IO bandwidth reservation mechanism like disk.usage_io_usage (perhaps per disk...).
Keep the good work, Rolando On Fri, Feb 20, 2009 at 10:21 AM, anqin <[email protected]> wrote: > ---------- Forwarded message ---------- > From: anqin <[email protected]> > Date: Fri, Feb 20, 2009 at 4:28 PM > Subject: [PATCH] cgroup for disk quota > To: Daniel Lezcano <[email protected]>, "Serge E. Hallyn" > <[email protected]>, [email protected] > Cc: Ian jonhson <[email protected]> > > > Dear all, > > For unified management of resources (CPU, memory, disk, network), > I (and Ian) developed a cgroup subsystem to control the usage > of disk quota. > > The subsystem for disk quota (disk_cgroup, to be brief) does accounting > of inode and block allocated by ext3/ext2 filesystem. Simarily as > filesystem quota, the disk_cgroup can do limitation but without needing > to open filesytem quota options (e.g. usrquota,grpquota in /etc/fstab). > Since this patch is first developed, it needs more feedback and testing > from other developers or users. > > The simple usage of disk_cgroup is as follows: > > # mount -t cgroup cgroup /mnt/cgrp > # lxc-execute -n lxc-template.conf /bin/bash > # ls /mnt/cgrp/11457/ // <-- 11457 is the pid of bash > ... > disk.stat > disk.usage_in_inode > disk.usage_in_block > disk.max_usage_in_inode > disk.max_usage_in_block > disk.limit_in_inode > disk.limit_in_inode > ... > > # echo 3 > /mnt/cgrp/11457/disk.max_usage_in_block > > # touch /tmp/mytestfile1 > # touch /tmp/mytestfile2 > # touch /tmp/mytestfile3 > # touch /tmp/mytestfile4 > touch: cannot touch `/tmp/mytestfile4': Disk quota exceeded > > The disk_cgroup is easily extended to manage complex objects > of filesystem. > > BTW, I don't know how to submit a "useful" patch to kernel community. Or, > maybe the patch is not useful at all and maybe has been developed by other > developers. I very appreciate if experts could give me some commend. > I will continue to develop cgroup-related codes to make contribution to kernel > development. > > Any comment is welcome, > > Anqin > > _______________________________________________ > Containers mailing list > [email protected] > https://lists.linux-foundation.org/mailman/listinfo/containers > _______________________________________________ Containers mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/containers _______________________________________________ Devel mailing list [email protected] https://openvz.org/mailman/listinfo/devel
