Re: container disk quota

[Jan Kara <jack-AlSwsSmVLrQ@public.gmane.org>]

On Mon 04-06-12 12:46:49, Jeff Liu wrote:
> On 06/04/2012 10:57 AM, Serge Hallyn wrote:
> > Quoting Jeff Liu (jeff.liu-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org):
> >> Hi Serge,
> >>
> >> On 06/02/2012 12:04 AM, Serge Hallyn wrote:
> >>
> >>> Quoting Jan Kara (jack-AlSwsSmVLrQ@public.gmane.org):
> >>>>   Hello,
> >>>>
> >>>> On Wed 30-05-12 22:58:54, jeff.liu-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org 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.
  GETQUOTA or SETQUOTA quotactls should work just fine inside a container
(for those quota-tools just need access to /proc/mounts). QUOTAON should
also work for e.g. XFS or ext4 with hidden quota files. When quota files
are visible in fs namespace (as for ext3 or so), things would be a bit
tricky because they won't be possibly visible from container and QUOTAON
needs that.

Also with QUOTAON there is the principial problem that quotas either are or
are not enabled for the whole filesystem. So probably the only reasonable
choice when you would like to supporot quotas in the container would be to
have quotas enabled all the time, and inside the container, you would just
set some quota limits or you won't...

								Honza
-- 
Jan Kara <jack-AlSwsSmVLrQ@public.gmane.org>
SUSE Labs, CR