From: Mefford, Aaron (amefford_at_about-inc.com)
Date: Thu 31 Oct 2002 - 16:08:12 GMT
> -----Original Message-----
> From: Andreas Kostyrka [mailto:andreas_at_mtg.co.at]
> Sent: Thursday, October 31, 2002 12:18 AM
> To: vserver_at_solucorp.qc.ca
> Subject: RE: [vserver] Quotas
> Am Mit, 2002-10-30 um 22.52 schrieb Mefford, Aaron:
> > I realize that I am new to the list and do not have much history, but I
> > considering the possibility of using vserver on a fairly large project
> > as such would like to at least take a moment to offer my opinion on a
> > of items.
> > First, I almost walked away from using the vserver option until after
> > joining the list I saw that the quota issue was being actively
> > Of the todo's left, quota was the biggest gap for my application. It
> > be excellent to see the others addressed but without quota it would not
> > an option.
> It surely should be. Consider using LVM and sticking each vserver on
> it's own logical volume. This way you can statically allocate space to
> vservers and resize their needs online.
I am not familiar with LVM but will quickly become familiar. As long as it
does not require a users space to be dedicated it will be a good answer it
seems. The problem with a filebased filesystem is the commitment of unused
> > As to the specific post, I am not sure that the hard line of not
> > is a good idea. While for many applications it would be a correct
> > there are some where it will not. Every ISP over allocates their
> > resources. People do not care to pay for dedicated resources.
> > Additionally, with most services now being offered via resellers, it
> > 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
> > allow Joe to oversubscribe his disk s pace, possibly even on a per VPS
> Thats what "soft" quotas are fore. Depending upon your guidelines when
> someone oversteps the softquota, either the root_at_main or root_at_vserver
> should decide if an upgrade of discstorage is needed and initiate it.
> Basically if you get 500MB/1000MB hard, you can overbook in the same
> ratio your own users, ...
Soft quotas might suffice, but not really what I am after. Say Joe is a web
developer who has bought a virtual server from me with 500 Mb of space. As
the service provider I want a hard quota that will not allow joe to exceed
500 Mb, and would typically set a soft quota at 80-90% so that joe gets
upgrade notices prior to running out of disk. Joe has a successful web
development business and has 100 clients whom he has developed sites for and
offers them hosting as well. Knowing these customers will only use 1-10 Meg
of actual disk as he designs there sites, yet wanting the customer to feel
comfortable that they are getting there moneys worth (every other provider
is oversubscribing as well and the apparent cost of 100M is 1/10 its actual
value) he gives each site 100M of quota. In doing this he knows that if one
of his clients logs in and fills there quota he will still have disk left,
and have the opportunity to upgrade to compensate after the fact. I monitor
my actual disk usage and by another shelf of disk whenever I reach 75%
usage. I have enough users that even if 10% of them decided to fill disk in
a short period of time, space would still be available.
> > I realize that implementing a solution that would support a hybrid
> > raises the complexity, but I wanted to state that there is value and
> > for such an approach.
> Well, the quota approach do have some problems (IMHO). Consider the
> vunified system files. Do they count against the "main" root quota, or
> against the "user" root quota? How is the Security Context a file
> belongs to stored on disc?
I think the majority of alternate products count unified files against
system root and configuration and other per VPS files against user root.