From: Mefford, Aaron (amefford_at_about-inc.com)
Date: Thu 31 Oct 2002 - 18:05:39 GMT
> -----Original Message-----
> From: Mefford, Aaron [mailto:amefford_at_about-inc.com]
> Sent: Thursday, October 31, 2002 8:45 AM
> To: 'vserver_at_solucorp.qc.ca'
> Subject: RE: [vserver] Quotas
> 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.
How funny, I meant Plesk. Sphera would never have pointed me to a better
product than their own. I apologize for that, I've been talking to too many
> > > 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
> resources and nothing else. Those people will buy dedicated servers or
> 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
> hand a max vserver quota that caps the vserver but allows the vserver
> 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
> 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
> 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
> > >> some users have not. This is the point of quota mechanism. Guarantee
> > >> space on the disk and not allow for over-booking. Allocated user
> > >> 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,
> > 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
> > >> 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