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

From: Dave (djp_at_comm.it)
Date: Wed 30 Oct 2002 - 14:31:08 GMT

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.

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

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. Now, after doing so much work you're trying to defend your
achievements from the "attacks".

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

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

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.

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.

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.

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


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