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) -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
