[lxc-devel] LXC quota support

[Daniel Lezcano]

anqin wrote:
> On Wed, Sep 2, 2009 at 2:32 AM, Daniel Lezcano<daniel.lezcano at free.fr> wrote:
>> Krzysztof Taraszka wrote:
>>> Hello,
>>>
>>> I am looking for quota support for LXC containers. For example, I would
>>> like
>>> to have two containers.  One of them may have 20GB, second 50GB.
>>> I found this one patch:
>>>
>>> https://lists.linux-foundation.org/pipermail/containers/2009-February/015807.htmland
>>> I have a question. Does there is another implemented method for have
>>> disk quota for container and his cgrop ? How about rootfs available disk
>>> space information ? If no, is there any ideas how to and when the disk
>>> quota
>>> will be implemented?
>> Anqui did a first try with this patch. The feature was positively received
>> but not in this form. I don't know what is the status of this work, but
>> maybe Anqui can give an answer :) - Cc'ed.
>>
>> Anqui ? Did you tried to implement quotas with the directory hierarchy level
>> as suggested Paul ?
>>
> 
> Yes, I am still in this work. I have attached a tag to directory
> hierarchy which
> can account the space consumption of each sub-directories and its files for
> different task groups. The way indeed can calculate the total disk consumpton
> of each group and limit its quota, however other trouble occurs when facing
> access control and security issue. I am dealing with the issue.


Excellent !

If you have a patchset, even not working nor tested or not compiled, I 
will be happy to review it.

>> Krzysztof, one solution to restrict disk usage to a container can be to
>> create an disk image of 20GB, mount it on a directory, install the rootfs on
>> it and use this directory as the rootfs for the container.
>>
> 
> This is another way to achieve same functionalities, by 'dd'ing image file
> with given quota and mounting as rootfs of task group. However, it is not
> easy to change the limited quota dynamically. This is not flexible enough
> for performance control (in green computing) and resource enforcement
> (in cloud computing).

Yep, agreed.

Thanks Anquin

   -- Daniel