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