On 03/12/2012 05:36 PM, Glauber Costa wrote:

On 03/11/2012 03:47 PM, Jeff Liu wrote:

quoted

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.

quoted

quoted

 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

configure,

quoted

 and have this quota be always smaller than, say, a project quota

defined

quoted

 for the container from the outside. But cgroups is hardly the

interface,

quoted

 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

quoted

 tying it to cgroups does not solve the fundamental problem, which

is how

quoted

 we have the container admin to set up quotas...

Sigh, exactly, I need some time to understand your opinions.  Thanks
again.

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.

-Jeff

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)