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

From: Jeff Liu <jeff.liu@oracle.com>
To: Glauber Costa <glommer@parallels.com>
Cc: jack@suse.cz, Lezcano <daniel.lezcano@free.fr>,
	lxc-devel@lists.sourceforge.net, Li Zefan <lizf@cn.fujitsu.com>,
	xfs@oss.sgi.com, Christoph Hellwig <hch@infradead.org>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
	Ben Myers <bpm@sgi.com>,
	tytso@MIT.EDU, Chris Mason <chris.mason@oracle.com>,
	Christopher Jones <christopher.jones@oracle.com>,
	tj@kernel.org, cgroups@vger.kernel.org, Daniel@oss.sgi.com
Subject: Re: [RFC PATCH v1 0/4] cgroup quota
Date: Mon, 12 Mar 2012 15:11:11 +0800	[thread overview]
Message-ID: <4F5DA18F.6040000@oracle.com> (raw)
In-Reply-To: <4F5DC396.60701@parallels.com>

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.

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

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs