From: Mefford, Aaron (amefford_at_about-inc.com)
Date: Thu 31 Oct 2002 - 15:45:09 GMT
Inline ...
> -----Original Message-----
> From: Herbert Poetzl [mailto:herbert_at_13thfloor.at]
> Sent: Wednesday, October 30, 2002 7:03 PM
> To: vserver_at_solucorp.qc.ca
> Subject: Re: [vserver] Quotas
>
> On Wed, Oct 30, 2002 at 02:52:14PM -0700, Mefford, Aaron wrote:
> > I realize that I am new to the list and do not have much history,
> > but I am considering the possibility of using vserver on a fairly
> > large project and as such would like to at least take a moment
> > to offer my opinion on a couple of items.
>
> I'm just curious: how did you find your way to the list?
A contact at Sphera pointed me in your direction. Additionally I found
reference to your project in the newsgroups.
>
> > First, I almost walked away from using the vserver option until
> > after joining the list I saw that the quota issue was being actively
> > addressed. Of the todo's left, quota was the biggest gap for my
> > application. It would be excellent to see the others addressed but
> > without quota it would not be an option.
>
> - so you actually require quota for your 'project'?
> - would you like to help us with the quota issue?
> - what about doing some testing?
>
> > As to the specific post, I am not sure that the hard line of not
> > overbooking is a good idea. While for many applications it
> > would be a correct solution there are some where it will not.
>
> > Every ISP over allocates their available resources.
>
> unfortunately that's true ...
And necessary for the internet to exist as it does.
>
> > People do not care to pay for dedicated resources.
>
> hmm, I think that depends on the clientele ...
True, very true, however that is why I said people and not something more
absoulute like businesses or enterprises.
Anyhow, there are always a few people that are willing to pay for guaranteed
resources and nothing else. Those people will buy dedicated servers or host
there own services. That is not the market I intend to target. Rather
those that want to appear dedicated but pay for shared.
>
> > Additionally, with most services now being offered via resellers,
> > it seems unreasonable to not allow the reseller the same option.
> > For instance, if I sell virtual private servers, and joe buys a
> > VPS with the intention of selling individual web sites run within
> > the VPS, I may or may not want to allow Joe to oversubscribe his
> > disk space, possibly even on a per VPS basis.
> >
> > I realize that implementing a solution that would support a
> > hybrid approach raises the complexity, but I wanted to state
> > that there is value and need for such an approach.
>
> what do you mean by hybrid approach?
> - that you would be able to set quota or leave it unset?
> - that you set the quota, but it might be ignored?
The hybrid approach I refer to is one that would allow by configuration a
vserver to guarantee (not oversubscribe) resources via quota or on the other
hand a max vserver quota that caps the vserver but allows the vserver admin
to oversubscribe within his own space. I would like to see the ability to
do both on the same system.
Oh... There was a question earlier as to what the appropriate response to a
super quota being exhausted while the user quota was not, while I would be
ok with the proposed quota exhausted message, IMO a disk full message seems
more appropriate.
>
> >>> - 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?
> >>
> >> IMHO, It should not be possible for a context to exceed it's quota when
> >> some users have not. This is the point of quota mechanism. Guarantee
> >> space on the disk and not allow for over-booking. Allocated user quota
> >> should be subtracted from the total context quota, so that any users
> >> with no quota should not be able to use that space. So in a way, users
>
> hmm, that might be the original idea of quota, but
> all current implementations do not guarantee, but only
> limit the maximum available resources ...
>
> if you want to guarantee, you then simply must do the
> math an make sure that enough physical disk space is
> available (or in the context case, the context quota
> lies above the sum of all user quotas)
>
> >> with quota will have their space, while other users will share what is
> >> left. It is the only way to guarantee file allocation.
> >>
> >> So, if context has 1Gig, and we allocate 300megs to users, all the
> other
> >> users will get at max 700megs.
>
> best,
> Herbert
Aaron