> -----Original Message----- > From: Mefford, Aaron [mailto:amefford@;about-inc.com] > Sent: Thursday, October 31, 2002 8:45 AM > To: '[EMAIL PROTECTED]' > Subject: RE: [vserver] Quotas > > Inline ... > > > -----Original Message----- > > From: Herbert Poetzl [mailto:herbert@;13thfloor.at] > > Sent: Wednesday, October 30, 2002 7:03 PM > > To: [EMAIL PROTECTED] > > 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 people. > > > > > 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
