Quotas in the Real World [TM] (was: Re: chown)

Nick Cuccia cuccia at yak.sybase.com
Sat Jul 8 14:32:47 AEST 1989


In article <4893 at ficc.uu.net> peter at ficc.uu.net (Peter da Silva) writes:
>In article <18414 at mimsy.UUCP>, chris at mimsy.UUCP (Chris Torek) writes:
>> The restriction is not bogus, because the system supports disk quotas.
>
>This assume that disk quotas are not bogus in a production environment.
>That is, outside a university...

Think about two or more administrative groups divvying up a large disk
partition.  (The real solution, of course, is to buy more disks (not
always practical from a financial point-of-view) or to repartition the
existing disk (not always practical, due to either limitations caused
by different vendors or the downtime required to repartition the existing
disk).  But I digress...).  Under such a system, quotas (or, something
almost like, but not exactly like the BSD or Sun quotas mechanisms) provide
the answer.

The problem that I have with the current quotas implementations is that
they're too limited in scope.  For the problem above, the current
implementations are useful--as long as the members of each group are
mutually exclusive (if your groups are beancounters and developers, then
that assumption is probably valid).  If, however, you have the more common
situation of users being members of multiple groups (three groups working
on the same application suite: one on front ends, another on servers and
back ends, and the other on networking support.  While the first two groups
may have a fairly small intersecting set with each other, they'd each have
quite a bit of intersection with the third), then you fall into the nightmare
of adjusting a user in the intersecting set's quotas so that his quota
doesn't cause any of his groups' quotas to be exceeded.

The fix is conceptually simple: allow for quota-by-group, as well as quota-by-
user.

--Nick
===============================================================================
          Some days, you just can't get rid of a bomb...--Batman
 Nick Cuccia			 System Admin/Postmaster, Sybase, Incorporated
 cuccia at sybase.com                     6475 Christie Av.  Emeryville, CA 94608
 {sun,lll-tis,pyramid,pacbell}!sybase!cuccia                   +1 415 596-3500
===============================================================================



More information about the Comp.unix.wizards mailing list