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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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)

xfs mailing list

[Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Photo]     [Yosemite News]    [Yosemite Photos]    [Free Online Dating]     [Linux Kernel]     [Linux SCSI]     [XFree86]

Add to Google Powered by Linux