Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/12/84; site desint.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxn!ihnp4!qantel!hplabs!sdcrdcf!trwrb!desint!geoff
From: geoff@desint.UUCP (Geoff Kuenning)
Newsgroups: net.micro.att,net.unix-wizards
Subject: Re: disk quotas
Message-ID: <118@desint.UUCP>
Date: Sat, 3-Aug-85 15:31:06 EDT
Article-I.D.: desint.118
Posted: Sat Aug  3 15:31:06 1985
Date-Received: Tue, 6-Aug-85 08:40:40 EDT
References: <133@maynard.UUCP> <396@cuae2.UUCP> <1025@ulysses.UUCP>
Reply-To: geoff@desint.UUCP (Geoff Kuenning)
Organization: SAH Consulting, Manhattan Beach, CA
Lines: 23
Xref: watmath net.micro.att:405 net.unix-wizards:14210

In article <1025@ulysses.UUCP> ggs@ulysses.UUCP (Griff Smith) writes (edited):
>
>If you haven't worked where people use UNIX systems to do real data
>processing, don't propose "ulimit" as an alternative to quotas.  A 50
>meg file won't even cause a batted eyelash here.  When you lose half a
>day because you forgot to cast the proper spell to bypass a per-file
>size limit, per-file-system limits look much more attractive...
>...We set our quotas very high,
>but they are convenient fire walls.

Sounds to me like quotas aren't really what you want, either.  You don't
want to set artificial limits on people's work (and any limit, no matter how
high, is going to be a problem for someone someday).  What you really want
is an OS that doesn't make it nearly impossible to deal with exceptional
conditions.  UNIX's response to a filled disk comes from the "panic:  out
of swap space" days when nobody really wanted to write the tough code because
it wasn't that important.  If Berkeley (or AT&T) would put as much effort into
the disk-full problem as was put into "swkill()" in 4.2, I bet you'd happily
stop using quotas.
-- 

	Geoff Kuenning
	...!ihnp4!trwrb!desint!geoff