Re: Thoughts on Quotas

[Michael Neumann <mneumann@xxxxxxxx>]

Am Dienstag, den 28.09.2010, 02:42 -0600 schrieb Samuel J. Greear:
> On Mon, Sep 27, 2010 at 10:34 PM, Chris Turner
> <c.turner@199technologies.org> wrote:
> > Samuel J. Greear wrote:
> >>
> >> 2^16 is nowhere close to enough. Quota's are very useful and to be
> >> useful you need to support hundreds of thousands of users. I consider
> >> lack of useful quota's to be one of our most major deficiencies.
> >
> > show me a single unix system with 100k's of users?
> >
> > I'm sure there's a few. but not 'hardly useful' if not supporting
> > less than 100k
> >
> > also:
> >
> > $ grep 'uid_t;' /usr/include/sys/types.h
> > typedef __uint32_t      uid_t;          /* user id */
> >
> > so like.. 32768 < 100k
> >
> > which isn't to say unix user/groups etc. is be-all-end-all
> > of "user systems" -
> >
> > but it works pretty well for most cases - and this statement
> > quite simply *not true* - run a workgroup lan for like 5 minutes -
> > and you'll find that 'hey this quota thing is a good idea'
> >
> 
> Virtual hosted mail, real disk quota's tend to be much more efficient
> and easy to manage than ad-hoc quota systems enforced by both an SMTP
> server and POP/IMAP server. In this case every virtual mail account
> gets a real uid within some range, but not an /etc/passwd entry or
> etc. -- This is definitely not an uncommon configuration.
> 
> Mass virtual hosted shared website hosts are in some cases cramming in
> the low 10,000's web accounts onto a single server now on relatively
> commodity hardware. That number will be in the hundred thousands 5
> years from now, I suspect.
> 
> HAMMER is an amazing filesystem to use as the underpinnings of a
> backup platform or NFS host for multiple head servers or etc., when
> you have a dozen or more machines hanging their storage off of one
> (maybe dozens or hundreds of heads in the future, when we see
> clustered HAMMER) pressure on uid's/gid's goes through the roof.
> 
> Quota systems are also often overloaded for accounting purposes, so
> before you think "well, quota's aren't useful in that scenario!", I
> have definitely tied quota's into billing at more than one employer
> under different scenarios in which the quota systems didn't actually
> enforce any limits on storage utilization. As an aside, perhaps this
> should be considered for any future quota implementation.
> 
> It is certainly possible that I am in the minority, but I definitely
> see hundreds of thousands as necessary now, it will be millions in the
> future.

Sure! I agree completely. My concern was just that historical data is
not taken into account, and some evil people can destroy your quota
system if they repetitively write to files without changing the file
size itself. I think for most cases quotas based on accumulating file
size as Matt has suggested will do. But will it also do when using
jails? I don't think it plays well with jails because there you want a
per-jail quota and not a per-user within a jail.

Now for my scenario (file/backup server) this per-user quota API would
do perfect. But then, as I want to give each user a PFS anyway (and I do
not think there are more than 100 users), so that each user can
configure history retention and mirroring individually, a per-PFS quota
sounds appealing as well, especially as ZFS has a similar feature :).

And a per-PFS allocation statistic would also be nice of course, which
is half of the implementation effort of my PFS-quota proposal.

> That isn't to say I think being able to place limits on a pfs is
> necessarily a bad idea, I can think of uses. Reservations might be
> useful too. I just don't see it replacing a quota system.

Both quota systems could live next to each other. PFS quota would be
more like file system resizing, but in a soft-manner.

Regards,

  Michael