On 03/12/2012 05:36 PM, Glauber Costa wrote:
> On 03/11/2012 03:47 PM, Jeff Liu wrote:
>> And also, if there has already a project quota limits enforced outsides
>> to a directly, but the user can still setup a smaller quota limit s
>> through cgroup ,those limits just mixed up, but the smaller quota only
>> be effected for those processes running at container.
>>> > What we really need here, is a way to have a privileged user inside a
>>> > container to create normal quotas (user, group) that he can
>>> > and have this quota be always smaller than, say, a project quota
>>> > for the container from the outside. But cgroups is hardly the
>>> > or place, for that: Usually, the processes inside the container won't
>>> > have access to their cgroups. They will contain the limits they are
>>> > entitled to, and we don't won't the processes to change that at
>>> will. So
>>> > tying it to cgroups does not solve the fundamental problem, which
>>> is how
>>> > we have the container admin to set up quotas...
>> Sigh, exactly, I need some time to understand your opinions. Thanks
> My take on this is that you should stick to the quota interface. It
> seems to works well enough for people out there. This means, how quotas
> are configured, viewed, etc, should work with standard tools.
> Now, we need some of those quotas to be tied to a particular mnt
> namespace (I believe namespaces to be the right isolation abstraction
> here, not cgroups), in the sense that they can only be active inside
> that mnt namespace. And then when you bill an inode, block, or anything
> else that quota limits, you bill it to any quota structure that is
> possibly interested in it.
I got started investigating how to isolate quota combine with namespaces today,
thanks for your timely suggestions, that's sounds clearer to me.
> Right now the code bills it to one quota
> structure, the one that matches your UID, GID, etc (XFS may be a bit
> more skilled already here, I don't know)