[Top] [All Lists]

Re: [RFC PATCH v1 0/4] cgroup quota

To: Glauber Costa <glommer@xxxxxxxxxxxxx>
Subject: Re: [RFC PATCH v1 0/4] cgroup quota
From: Jeff Liu <jeff.liu@xxxxxxxxxx>
Date: Mon, 12 Mar 2012 15:11:11 +0800
Cc: jack@xxxxxxx, Lezcano <daniel.lezcano@xxxxxxx>, Christopher Jones <christopher.jones@xxxxxxxxxx>, Li Zefan <lizf@xxxxxxxxxxxxxx>, xfs@xxxxxxxxxxx, Christoph Hellwig <hch@xxxxxxxxxxxxx>, tj@xxxxxxxxxx, Ben Myers <bpm@xxxxxxx>, Daniel@xxxxxxxxxxx, lxc-devel@xxxxxxxxxxxxxxxxxxxxx, "linux-fsdevel@xxxxxxxxxxxxxxx" <linux-fsdevel@xxxxxxxxxxxxxxx>, cgroups@xxxxxxxxxxxxxxx, Chris Mason <chris.mason@xxxxxxxxxx>, tytso@xxxxxxx
In-reply-to: <4F5DC396.60701@xxxxxxxxxxxxx>
Organization: Oracle
References: <4F59E78A.7060903@xxxxxxxxxx> <4F5C933F.3000409@xxxxxxxxxxxxx> <4F5C90DF.8070605@xxxxxxxxxx> <4F5DC396.60701@xxxxxxxxxxxxx>
Reply-to: jeff.liu@xxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20110617 Thunderbird/3.1.11
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
>>> configure,
>>> >  and have this quota be always smaller than, say, a project quota
>>> defined
>>> >  for the container from the outside. But cgroups is hardly the
>>> interface,
>>> >  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
>> 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.


> 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)

<Prev in Thread] Current Thread [Next in Thread>