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 - 00:09:39 GMT

On Tue, Oct 29, 2002 at 05:52:23PM -0500, Jacques Gelinas wrote:
> On Tue, 29 Oct 2002 12:41:20 -0500, Dave wrote
> > For example I don't mind if the context has to be fixed for each
> > vserver, if this was the price for not having to patch userland tools.
> > If we combine the 16bit uid + 16bit context, there're still 64K servers
> > to be created before we run out of "virtuals" on the same machine.
> > Right?
> Btw, for those who want to play with special context (assigned by hand),
> I can change the kernel so on-the-fly security context are allocated
> from 1000 and up making sure the one you have select by hand will
> only be used by this vserver.
> My idea about vserver quota was a little like that. Some uid remapping.
> I was adding another tricks. The quota of all users in a vserver was
> summed and enter as a special user. Each vserver would be associated
> with a special users. For example, if vserver foo is created, then user
> quota_foo would be created and it would be possible to limit globally
> a vserver just by limiting user quota_foo.

sorry guys, but I am obviously missing something ...

To clear things up, for you and for me, I'll give you
my personal perspective of the quota issue ...

Some time around July 2002, I just started posting to
the VServer mailing list, there was a discussion about
using separate LVM shares for each context (breaking
unification) to achieve per context quota support.

I thought, "that is an obviously ugly hack to get
some kind of context quota into VServer", and remembered
there was something in the documentation about combining
context and user information into 32bit uids and use
them for context specific quota.

I looked at the kernel sources, and to my suprise I
found that the current implementation (of quota in
the kernel) wisely foresaw an arbitrary number of
different quota types ...

I asked the list members to send suggestions and/or
ideas, regarding this issue to me (or the list), but
never received any feedback. So I put that issue
on the shelf, and did something else ...

Last week I read something like "lets work together
and make context quota a reality in the next vserver
release", an I thought, okay if somebody actually wants
to do it, or someone can make use of it, I'll try to
help, if I can.

Then suddenly and unfortunately the mailing list
(and the web space) went down (at least a name server
problem) and the only contact I had was the person
who suggested to work on quota ...

I had some spare time at the weekend, and thought
to myself, give it a try, and implement something, which
can be used as a base for context quota, etc, etc ...

The next day, the basic modifications were done, and
my contact was able to actually test the stuff ...

I thought, this would be of interest, and maybe one
or the other vserver admin/user/tester would try it
and give some comments and/or bug reports. And over
some time there will be a stable context quota for
the vserver project.

The next thing I read was that the kernel design
must be bad, and that context quota and/or userland
support for it is depreciated???

But still, there is no response to my implementation
and nobody seems to be interested in the topic
anymore ...

I will seize my work on that issue immediately,
until the community (or Jacques) decides which
kind of solution is apt for vserver, and if it
seems apropriate, continue the development ...

Ad Dave: I want to apologize for my harsh reply.

Ad Jacques: I did not want to drive vserver in a
  direction you obviously do not value, but you
  could have elaborated more about your quota
  concepts ...


PS: don't get me wrong, I obviously did get you wrong.

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