[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4FCC3DB9.40105@oracle.com>
Date: Mon, 04 Jun 2012 12:46:49 +0800
From: Jeff Liu <jeff.liu@...cle.com>
To: Serge Hallyn <serge.hallyn@...onical.com>
CC: Jan Kara <jack@...e.cz>, tytso@....edu,
containers@...ts.linux-foundation.org, david@...morbit.com,
hch@...radead.org, bpm@....com, christopher.jones@...cle.com,
linux-fsdevel@...r.kernel.org, cgroups@...r.kernel.org, tm@....ma,
linux-ext4@...r.kernel.org, chris.mason@...cle.com,
tinguely@....com
Subject: Re: container disk quota
On 06/04/2012 10:57 AM, Serge Hallyn wrote:
> Quoting Jeff Liu (jeff.liu@...cle.com):
>> Hi Serge,
>>
>> On 06/02/2012 12:04 AM, Serge Hallyn wrote:
>>
>>> Quoting Jan Kara (jack@...e.cz):
>>>> Hello,
>>>>
>>>> On Wed 30-05-12 22:58:54, jeff.liu@...cle.com wrote:
>>>>> According to glauber's comments regarding container disk quota, it should be binded to mount
>>>>> namespace rather than cgroup.
>>>>>
>>>>> Per my try out, it works just fine by combining with userland quota utilitly in this way.
>>>>> However, they are something has to be done at user tools too IMHO.
>>>>>
>>>>> Currently, the patchset is in very initial phase, I'd like to post it early to seek more
>>>>> feedbacks from you guys.
>>>>>
>>>>> Hopefully I can clarify my ideas clearly.
>>>> So what I miss in this introductory email is some highlevel description
>>>> like what is the desired functionality you try to implement and what is it
>>>> good for. Looking at the examples below, it seems you want to be able to
>>>> set quota limits for namespace-uid (and also namespace-gid???) pairs, am I
>>>> right?
>>>>
>>>> If yes, then I would like to understand one thing: When writing to a
>>>> file, used space is accounted to the owner of the file. Now how do we
>>>> determine owning namespace? Do you implicitely assume that only processes
>>>> from one namespace will be able to access the file?
>>>>
>>>> Honza
>>>
>>> Not having looked closely at the original patchset, let me ask - is this
>>> feature going to be a freebie with Eric's usernamespace patches?
>>
>> It we can reach a consensus to bind quota on mount namespace for
>> container or other things maybe.
>> I think it definitely should depends on user namespace.
>>
>>>
>>> There, a container can be started in its own user namespace. It's uid
>>> 1000 will be mapped to something like 1101000 on the host. So the actual
>>> uid against who the quota is counted is 1101000. In another container,
>>> uid 1000 will be mapped to 1201000, and again quota will be counted against
>>> 1201000.
>>
>> Is it also an implications that we can examine do container quota or not
>> based on the uid/gid number?
>
> I'm sorry I don't understand the question.
Sorry for my poor english.
>
> As an attempt at an answer: the quota code wouldn't change at all. We would
> simply exploit the fact that uid 1000 in container1 has a real uid of 101100,
> which is different from the real uid 102100 assigned to uid 1000 in container2
> and from real uid 1000 (uid 1000 on the host).
In that case, looks we only need to figure out how to let quota tools
works at container.
I'll build a new kernel with user_ns to give a try.
>
>>> Note that this won't work with bind mounts, as a file can only be owned
>>> by one uid, be it 1000, 1101000, or 1201000. So for the quota to work
>>> each container would need its own files. (Of course the underlying
>>> metadata can be shared through whatever ways - btrfs, lvm snapshotting,
>>> etc)
>>
>> Do you means that we can not bind mount outside files to container for
>> as general adquot.user/adquot.group purpose?
>
> Right, not without some sort of stackable filesystem which masks the uid.
>
> Actually there may be a way around it (simply provide a mount option,
> requiring privilege in the original user namespace, saying mask uid x to
> look like uid y for this bind mount), but it's too early to say how
> cleanly that could be done.
>
>> If so, per glauber's comments, bind quota to mount namespace should be a
>> generic feature, and container just one of users could make use of it.
>>
>> Again, if bind quota to mount namespace is on right direction, and it
>> only does make sense to container for now, maybe we don't need such
>> files. IMHO, container is a lightweight virtualization solution, maybe
>> its fine to make it as simple as possible. If the server admin need to
>> configure hundreds of user/group dquot per container, perhaps he should
>> consider KVM/XEN.
>
> Server admin doesn't need to do that.
Thanks for the info!
-Jeff
>
> -serge
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists