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

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

 



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. 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@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs


[Index of Archives]     [Linux XFS Devel]     [Linux Filesystem Development]     [Filesystem Testing]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux