About this list Date view Thread view Subject view Author view Attachment view

From: Herbert Poetzl (herbert_at_13thfloor.at)
Date: Wed 30 Oct 2002 - 12:58:54 GMT

On Wed, Oct 30, 2002 at 09:31:08AM -0500, Dave wrote:
> On Tue, 2002-10-29 at 07:11, Herbert Poetzl wrote:
> > forgive me, if I may sound harsh, but maybe you should
> > a) take a closer look on the issue/subject
> > b) read the fine pages I put up ...
> > c) switch the brain on (sorry about that)
> Brain is on. Loadavg is somewhat high to study the *all* code, but still
> usable to understand the schenario :-)
> > but be so nice and explain to me the following:
> >
> > - if the quota tools are somewhat badly designed to
> > only recognize TWO KINDS of quota (user/group)
> > how would it be possible to design the kernel
> > extension, to NOT REQUIRE CHANGING the tools?
> If you use the quota tools from withing the context X, the kernel shall
> not need to be told that we're talking about context X, nor about a
> context quota at all. The context will be implied and mandatory. We
> don't want to be able to change quota in another context. When speaking
> about the total vserver quota, that should only be manageable from
> context 0.

I totally agree on that, but as Nuno Silva said,
there are different quota aspects, and to clarify
I will try to explain them (from my point of view)

A) user/group quota within a context
   should ...

   - be working like on any other machine ..
   - need no modifications to userland tools at all
   - be only valid and accounting for the context

B) physical server per context user/group quota
   should ...
   - work like usual, but give information about the context
   - be able to set specific context/user context/group quota
   - will require changes in userland tools ...

C) context quota (total sum of users per context)
   should ...
   - work like user or group quota, but based on the context
   - need no changes for quota tools, if they are general
     enough to handle all kernel quotas (not only user/group)

> All the information that the kernel needs is already there. There's no
> need to patch the quota tools.

agreed for A) and for C) after some quota-tools rewrite ...
> I think that you saw the kernel code, and then jumped with two feet on
> the wagon, in what seemed to be the easies way to implement the quota
> stuff.

thats right, but it also seems to be the elegantest
solution from the kernel perspective ...

> Now, after doing so much work you're trying to defend your
> achievements from the "attacks".

I have no problem with "constructive" criticism, but
I don't like it, if somebody, who has not even looked
at the stuff I wrote, nor understood the ideas behind,
says "hey pal, that's crap!"

(please don't get me wrong, take a look at it, ask
me if something is not understood, any ideas and/or
suggestions are really apreciated ...)

> I was trying to be "constructive" and to give this issue a more generic
> view.


> > - why do you think, it is required to modify the
> > administration tools? If you don't need the new
> > features, almost nothing has changed, and the
> > whole thing is transparent within a vserver
> What I'm saying is that we're not implementing NEW things. Setting a
> quota for a user within the context should not be different from setting
> a user quota out of the context.

I assure you, this is, and always was, my goal ...

> If we modify the quota tools to be aware of the context, we'll brake
> existing software. We won't be able to run commercial software (i.e.
> software we cannot recompile) inside a virtual server. And we'll have to
> patch every single piece of software that deals with quotas. I'm sure
> you get the point.

> > > A better design will simplify the work of maintaining the ctx patch in
> > > the future. We won't need to keep up to date with the userland tools
> > > too.
> >
> > you will always have to keep up with userland tools
> > as long as you want to administer your virtual servers ..
> > (think about it)

> I think I have demonstrated above, that from a semantic point of view,
> the context is a kernel-only information. When tied to the filesystem,
> you may have to use a constant context for each virtual server, but
> that's all it takes. The quotatools patches may be an easier way to
> obtain a result, but come at a running cost and are not exactly an
> elegant solution.

I never, ever tried to make the quota-tools within a context
aware of the context ...

> Maybe all that is needed now is to get the kernel to add the context
> information automatically, instead of patching the quota tools to
> provide it and check for its validity. This will be a much better and
> more general solution.

the special user aproach (for context quota information) seems
tempting, but in my opinion there are several drawbacks ...

- how to make sure, that no real uid uses these values
- the total sum of all user accounts usually is equal to
  the size of the filesystem (some tools might rely on that)
  now the total equals (N+1) times the size of the filesystem
  (N being the number of contexts)
- how to handle context quota violations within the kernel
  for users which do not exceed their personal quota?
  Simply report you exceeded your quota, and on check report
  that still space/quota is left?

> This, plus the "global user" suggested by Jacques to keep track of the
> whole vserver size might well be the definitive quota support we're all
> looking for.

my approach gives standard quota support for user/group
but for each context ... no change within the vserver
is required ... and you get a third kind of quota, which
accounts for the whole context, and if the quota-tools
are written properly (which means to look in the kernel
how many different kinds of quotas there are), they will
be able to report the context quota as well ... if not
then not, no problem ...

what you will ned, and want, are tools to set/view/manipulate
quota and context information on the physical server, but
the whole vserver project would not work without
chcontext, chbind and other userland tools, aware of the
new kernel features ...

> I hope that you don't feel too frustrated by the slight difference of my
> point of view (functional rather than implementation), and I admit that
> I haven't studied the quotatools implementation yet. I promise to do so
> asap so I can be more precise when suggesting solutions (and avoid
> saying too much non-sense).

no, absolutely not, because it seems that now some kind
of discussion is going on, and as usual, discussion will
solve the problems we encounter here ...


About this list Date view Thread view Subject view Author view Attachment view
[Next/Previous Months] [Main vserver Project Homepage] [Howto Subscribe/Unsubscribe] [Paul Sladen's vserver stuff]
Generated on Wed 06 Nov 2002 - 07:03:43 GMT by hypermail 2.1.3